-
Notifications
You must be signed in to change notification settings - Fork 640
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to merge release back to develop (OBSOLETE PULL REQUEST) #290
Closed
dtabuenc
wants to merge
132
commits into
GitTools:merge-release-back-to-develop
from
dtabuenc:merge-release-back-to-develop
Closed
Ability to merge release back to develop (OBSOLETE PULL REQUEST) #290
dtabuenc
wants to merge
132
commits into
GitTools:merge-release-back-to-develop
from
dtabuenc:merge-release-back-to-develop
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Added skipIfNotDefined for upcoming Continua CI v1.5
we dont rely on fody anymore
reduces the use of the Arguments god class
no longer needed in the core
Added support for NextVersion.txt in GitFlow and dynamic repositories
should get exact version from tag
First attempt at adding support for Stash Pull Requests. NOTE: While all the tests are passing, I haven't actually tested this on an actual Stash Server, as I don't currently have one of those :-)
Changed the BuildServer class to be private, rather than public, based on the suggestion from the ReSharper Code Inspection.
- As per discussion here: GitTools#262 - Changed to use the AppVeyor REST API SetVariable method, instead of setting an Environment Variable
(Correction) AppVeyor - Changed to using REST API when calling GenerateSetParameterMessage
- Based on a suggestion from @nulltoken, skipping the creation of the HEAD branch, if it exists in the list of branches to create. - This was causing an issue when running on AppVeyor - This can be seen working here: https://ci.appveyor.com/project/GaryEwanPark/webapisample/build/0.2.0-unstable.23+23%20(Build%2034)
Skip creation of HEAD branch when creating local branches
This preserves the correct version when merging a release back into develop. This also changes the semantics of the 0+1 part of the semantic version so that it represents the number of changes since the previous tagged release (e.g. version 1.0.0-beta.1+5 gets reset to 1.0.0-beta.2+0)
dtabuenc
force-pushed
the
merge-release-back-to-develop
branch
from
November 8, 2014 07:35
84ad565
to
1dc79b7
Compare
Closed and re-submitted as #291 which is based off of newest master |
dtabuenc
changed the title
Ability to merge release back to develop
Ability to merge release back to develop (OBSOLETE PULL REQUEST)
Nov 8, 2014
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This preserves the correct version when merging a release back into develop.
There are some behavioral changes as shown in the edited tests:
The behavior of the +n CommitsSinceTag metadata is changed to actually represent the comits since last tag. This means that this number gets reset to zero on change of PreReleaseTag. For instance, version 1.0.0-beta.1+5 gets reset to 1.0.0-beta.2+0 for the next commit after the 1.0.0-beta.1 tag). When only one tag is present, (i.e. the first tag in the release branch) it reverts to the previous behavior which is to indicate the number of commits since the creation of the release branch.
There are also two other test that broke, but do not make sense to me. As far as I understand if I tag a commit as 1.2.1-beta.1 it should not change the version to 1.2.1-beta.2 until the next commit after the tag. This confused me in the wiki diagrams as well and does not work the way the current version of GitVersion (installed from chocolatey) works.
If I tag a certain commit as 1.2.1-beta.1 I am expecting to freeze the version of that commit as 1.2.1-beta.1. So unless I am missing something, these tests seem wrong to me. Please feel free to enlighten me if things should work as specificed in the tests.