ExamTopics Logo
Mail Us[email protected]
Menu
Microsoft Discussions
exam questions

Exam AZ-400 All Questions

View all questions & answers for the AZ-400 exam
Go to Exam

Exam AZ-400 topic 8 question 69 discussion

Actual exam question from Microsoft's AZ-400
Question #: 69
Topic #: 8
[All AZ-400 Questions]

DRAG DROP
-

You are designing a versioning strategy for Git-based packages.

You plan to use a Semantic Versioning (SemVer)-based strategy.

You need to identify when to change the build version.

What should you identify for each scenario? To answer, drag the appropriate versions to the correct scenarios. Each version may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view content.

NOTE: Each correct selection is worth one point.

Show Suggested Answer Hide Answer
Suggested Answer:
by meee21 at Jan. 19, 2023, 2:05 p.m.

Comments

Chosen Answer:
This is a voting comment (?). It is better to Upvote an existing comment if you don't have anything to add.
Switch to a voting comment New
Submit Cancel
mrg998
Highly Voted 2 years, 1 month ago
I would say: Minor Major Patch
upvoted 22 times
Mattt
5 months ago
patch is for bugfixing Major Minor Minor
upvoted 5 times
...
...
meee21
Highly Voted 2 years, 1 month ago
correct 1- https://learn.microsoft.com/en-us/aspnet/core/diagnostics/mvc1004?view=aspnetcore-7.0#:~:text=Renaming%20a%20parameter%20on%20a%20public%20type%20could%20be%20considered%20a%20breaking%20change%20since%20it%20changes%20a%20library%27s%20public%20API%20surface. 2,3 - https://semver.org/#:~:text=Minor%20version%20Y,version%20is%20incremented.
upvoted 13 times
mrg998
2 years, 1 month ago
i change my comment, this is the right answer
upvoted 6 times
...
...
Gooldmember
Most Recent 4 months, 1 week ago
Major Minor Minor
upvoted 1 times
...
4bd3116
10 months ago
Correct
upvoted 1 times
...
renzoku
1 year, 8 months ago
MAJOR, Rename a parameter in an API, potential to cause backward-incompatibility if the parameter is referenced in some part of the code MINOR, Deprecate a funcionality in an API, it won't cause backward-incompatibility inmediatly because you only mark it like deprecated and provide the warning that the funcionality will be removed in future versions MINOR, Add a feature and maintain backwards compatibility, because won't cause backward-incompatibility
upvoted 12 times
Mattt
5 months, 1 week ago
correct
upvoted 1 times
...
...
zellck
1 year, 9 months ago
1. Major 2. Minor 3. Minor https://semver.org/ Given a version number MAJOR.MINOR.PATCH, increment the: - MAJOR version when you make incompatible API changes - MINOR version when you add functionality in a backward compatible manner - PATCH version when you make backward compatible bug fixes
upvoted 6 times
zellck
1 year, 9 months ago
https://semver.org/#how-should-i-handle-deprecating-functionality Deprecating existing functionality is a normal part of software development and is often required to make forward progress. When you deprecate part of your public API, you should do two things: (1) update your documentation to let users know about the change, (2) issue a new minor release with the deprecation in place. Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.
upvoted 4 times
...
...
aut0pil0t
1 year, 11 months ago
Rename parameter in API - Major (incompatible API change) Deprecate functionality in API - Major (incompatible API change) Add a feature and maintain backward compatibility - Minor (backward compatible "feature") https://semver.org/
upvoted 2 times
xRiot007
1 year, 7 months ago
You clearly didn't read the semver site content, did you ? Let me cite it for you : https://semver.org/#spec-item-7 " Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented."
upvoted 1 times
...
xRiot007
1 year, 7 months ago
Deprecate is Minor - you are just informing the user that some contract methods are obsolete. Those methods will still work, so it's totally compatible API change because you just inform the users that these methods are obsolete. Later releases will remove these methods altogether (this is a major change, not the deprecation).
upvoted 2 times
...
...
le129
2 years ago
how is renaming a parameter major but not deprecating functionality? both are breaking changes?
upvoted 5 times
OpOmOp
1 year, 11 months ago
In semver, a change is considered major if it breaks backward compatibility, meaning that existing code that relies on the API will no longer work as expected after the change is made
upvoted 3 times
OpOmOp
1 year, 11 months ago
a minor change is one that adds new functionality in a backward-compatible manner, or deprecates existing functionality in a backward-compatible manner. Since deprecating functionality in an API does not break existing code, it is considered a minor change.
upvoted 4 times
PDR
1 year, 8 months ago
I would argue that it could break existing code if something relies on that API functionality to obtain certain responses it relies on. Debatable of course as to 'whos problem' that is and could say it was a result of not handling errors properly but the reality of the situation remains the same.
upvoted 2 times
hotspot02103
2 months, 1 week ago
deprecating != removing functionality is still there, you can use it, just you (should) receive a ton of warnings. At the time the functionality is __removed__ then it becomes a Major SemVer change
upvoted 1 times
...
...
...
...
zellck
1 year, 9 months ago
https://semver.org/#how-should-i-handle-deprecating-functionality Deprecating existing functionality is a normal part of software development and is often required to make forward progress. When you deprecate part of your public API, you should do two things: (1) update your documentation to let users know about the change, (2) issue a new minor release with the deprecation in place. Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API.
upvoted 3 times
...
...
Frefren
2 years, 1 month ago
Correct. Major, Minor, Minor The last one is not patch, because it adds a feature, not fix a bug.
upvoted 3 times
...
Community vote distribution
A (35%)
C (25%)
B (20%)
Other
Most Voted
A voting comment increases the vote count for the chosen answer by one.

Upvoting a comment with a selected answer will also increase the vote count towards that answer by one. So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.

SaveCancel
exam
Someone Bought Contributor Access for:
SY0-701
London, 1 minute ago