-
Notifications
You must be signed in to change notification settings - Fork 651
Improve story for adding GitVersion into legacy repository #296
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
Comments
@gep13 Thanks for creating this issue! Having a fallback strategy would be great! As I have problems with getting GitVersion to understand another repository layout as well (as explained in #283) and there are other issues asking for configurability of the repository layout (like #292), perhaps the way to solve all of these is a way to explain to GitVersion how the layout is, what represents the branch that ultimately should produce stable NuGet packages, what branches should produce prerelease ones, how the tags look like, etc. |
@asbjornu yes, I think that this is something that we need to work towards as well. |
Suggestion to fix: We should fall back to the last reachable tag if the same merge commit strategy doesn't work |
Figured it out finally. GitFlow assumes that tags are only Easy fix! |
Awesome! Looks like a beautiful solution as well: 315 deletions. 😃 |
Love it when a fix involves deleting code! Sent from my Windows Phone From: Asbjørn Ulsbergmailto:[email protected] Awesome! Looks like a beautiful solution as well: 315 deletions. [:smiley:] — |
As discussed here:
getsentry/raven-csharp@2b08830#commitcomment-8521534
@JakeGinnivan came up with the following
I think develop version calculation is broken for this scenario...
Basically the issue is that there is 'special' version calculation logic for the develop branch, so the tags do not have to be reachable by develop. This is so after you merge the release branch into master you don't have to merge master into develop.
It looks for a merge commit with the same name on both master and develop. It then looks for a tag on that merge commit, and that is the last common version which is used to calculate.
It's crap, but you have to:
There should be a better story for this, I haven't done much work with the GitFlow side of things. After you have done this you should be fine going forward
The text was updated successfully, but these errors were encountered: