SemVer 2.0 support about gitversion

[andreasohlund]

Regarding the "Unstable":

Since we're using Ripple (http://darthfubumvc.github.io/ripple/ripple/index/) to make sure our develop branches always stay up to date with our upstream deps we need to make sure that what comes out of the develop builds is always considered to be the most recent version. And since NuGet don't yet have a concept of builds we need to make sure that it sorts highest , hence the name Unstable since its > Alpha, Beta, RC etc

This is obviously a little unfortunate and we'll change accordingly as soon as NuGet gets its act together:)

That said you can have other requirements so this can easily be configurable. Should we work together to get a pull request going that sorts this out for you?

[SimonCropp]

@distantcam

The root of the problem here is that, AFAIK, SemVer make no allowance for CI builds

This has bee much discussed (http://haacked.com/archive/2011/10/24/semver-nuget-nightly-builds.aspx) but I have seen no good way to handle it.

the problem is that, in terms of precedence, CI builds are interleaved with pre release.

For example say chronologically we have the following

• CI build 1
• CI build 2
• Preparing for release so Beta 1
• CI build 3
• closer to release so Beta 2
• CI build 4
• Almost there so RC 1
• CI build 5
• Release is done so "final" release number

Now if we use alpha for CI builds this results in the following precedence order.

• CI build 1 (Alpha 1)
• CI build 2 (Alpha 2)
• CI build 3 (Alpha 3)
• CI build 4 (Alpha 4)
• CI build 5 (Alpha 5)
• Preparing for release so Beta 1
• closer to release so Beta 2
• Almost there so RC 1
• Release is done so "final" release number

Which is not great because if someone says they want to use the "latest unstable" they will never get the CI versions after a beta has been release.

So rather than try and force SemVer to meet our CI requirements we have decided to step outside the spec for this case. "Unstable" was chosen because it is a pre-exiting pseudo standard on nuget.

There is still the issue of nuget will precedence sort "Unstable" higher than alpha, beta and RC. To work around this we have moved our CI builds to myget. The result is that we only list proper semver versions on the official nuget feed and the sorting works as expected. If people want to live on the edge they can switch to the myget feed.

Happy to hear more ideas on how to solve this issue.

Just to be clear i am not against having a switch to use "alpha" for CI builds but i dont think it solves the root issue.

[JakeGinnivan]

@SimonCropp I think that the develop branch is not semantically versioned, which is the root problem.

When you create a release branch, you decide that the next semver will be 1.2.3, this means that it has a higher version number than develop, BUT it is a pre-release package.

If you accept that develop is not semantically versioned, and you drop it back to a traditional version number, you will get {lastMajor}.{lastMinor}.{lastPatch}.{buildNumber}. This is a stable package, which means you continuous integration can just continuously integrate stable packages. OR if you want staged releases to take precedence you can include pre-release, then as soon as you take your release branch, the packages from that will be taken over the packages from develop

Feature branches take the same approach as develop where they are not semantically versioned (by having a 4 part version number), but still use the pre-release tags that semver uses.

Once you move to the release branches they are semantically versioned, and you use build metadata to differentiate the ordering. For example 1.2.3-alpha+001, 1.2.3-alpha+002.
My understanding is that while you cannot take a dependency on a specific build you can have multiple of them in a single feed, and the latest will just be chosen.
If you need people to be able to upgrade between a release build then just tag the release to bump the tag?

[distantcam]

I have to agree with @JakeGinnivan, develop and features should not be versioned in the same schema as master and releases. Keeping them in a separate NuGet stream, or not even bothering to add them works for me.

I'm happy enough to create a PR to support this, but I'm wondering how that sort of thing would be configured. I'm using the MSBuild task version, so that's the scenario I'm most interested in configuring.

[JakeGinnivan]

Im thinking that develop falls back to normal 4 part versioning. For example.

I tag 2.4.3 on master, the next develop builds should be 2.4.3.x, where x is the number of commits since the tag on master. Feature branches are the same, but pre-release, i.e 2.4.3.5-featurefoo or whatever it is.

Once you move over to a hotfix or release branch then the major, minor or patch change and the 4th number drops back to 0.

This solves the CI build issue quite well, and personally makes sense (as develop normally has no semver info, unless we added the nextversion.txt or scanned commits).

I have to think a bit more about GitHubFlow as master should always be correctly Semantically versioned to allow continuous delivery.

Sent from my Windows Phone

---

From: Cameron MacFarlandmailto:[email protected]
Sent: ý24/ý01/ý2014 08:42
To: Particular/GitFlowVersionmailto:[email protected]
Cc: Jake Ginnivanmailto:[email protected]
Subject: Re: [GitFlowVersion] SemVer 2.0 support (#13)

I have to agree with @JakeGinnivanhttps://github.com/JakeGinnivan, develop and features should not be versioned in the same schema as master and releases. Keeping them in a separate NuGet stream, or not even bothering to add them works for me.

I'm happy enough to create a PR to support this, but I'm wondering how that sort of thing would be configured. I'm using the MSBuild task version, so that's the scenario I'm most interested in configuring.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-33201074.

[andreasohlund]

I think that the develop branch is not semantically versioned, which is the root problem.

From our perspective we want the develop to be SemVer'ed since we make have use of Obsolete(Ex) and we want the develop to reflect that "upcoming release semver" in or for us to get compile errors as the version goes up on master.

Not sure if strict semver is needed for the above though

[distantcam]

It sounds like GitFlowVersion is currently hard coded for Particular's way of versioning, which won't suit everyone.

So, what about a template based string to represent the version for the different branch types? Each project could setup their own versions the way they want.

Thoughts? Possible?

[andreasohlund]

It sounds like GitFlowVersion is currently hard coded for Particular's
way of versioning, which won't suit everyone.

Totally agree (just explaining the reasoning), since the "versionfinders"
are pluggable we should be able to make this configurable?

On Fri, Jan 24, 2014 at 9:37 AM, Cameron MacFarland <
[email protected]> wrote:

It sounds like GitFlowVersion is currently hard coded for Particular's way
of versioning, which won't suit everyone.

So, what about a template based string to represent the version for the
different branch types? Each project could setup their own versions the way
they want.

Thoughts? Possible?

Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-33205632
.

[JakeGinnivan]

I am thinking that it would be good to support something like this:

major.minor.patch.increment

1.2.3 < 1.2.3.2
1.2.3.2 < 1.3.0

This allows CI builds to increment after a release and have a nightly feed between releases.

Then just build that logic into your ObsoleteEx

Then we get the best of both worlds

[JakeGinnivan]

Pretty sure we are SemVer 2.0 compliant now.

@distantcam want to check it out?