Adopt Semantic Versioning 2.0.0-rc.1

[adamralph]

http://semver.org/

Main points:

1. drop the fourth element from the version scheme
2. increment major when making breaking change, resetting minor to zero
3. increment minor for all other releases, resetting patch to zero
4. increment patch only when fixing a bug

[patrik-hagne]

This is great, something I've wanted for a long time!

[philippdolder]

definitely

[adamralph]

As part of completing this task, we'll have to decide what the version number is going to be for our next release.

According to SemVer we should at least increment the minor, so I've tentatively set the version to 1.8.0 in the pull request.

Interestingly, with the removal of SL3 support in #38, do we consider that a breaking change? Ultimately, as Eric Lippert has shown, any change is potentially a breaking change but in my opinion we need to be subjective about what we consider to be a breaking change. In the case of SL3 removal I don't think we should consider this a breaking change. The fact is, any SL3 client simply won't be able to use the package outright, rather than just something breaking for it. So my vote would be incrementing to 1.8.0 with regard to this change.

We also have to consider all other changes made since the last release. Is there any way of telling which revision the current release was made from? If any subsequent revisions contain breaking changes then we will have increment to 2.0.0.

[patrik-hagne]

I don't consider removal of SL3 support a breaking change, it couldn't be 'cause it's ultimately not a change at all to the consumers of the non SL3-versions.

To me, what Eric says is that every public change is a possible breaking change. I think that we should only consider those changes that inevatibely are breaking as breaking. For example, the removal of a method, the adding of a parameter and such, these are breaking changes. Addition of new types or adding methods to existing types should in general not be considered as breaking changes.

There's no easy way of telling which revision it was made from, this is something that I would like in the future.

[adamralph]

Great, I completely agree with your interpretation of breaking changes . I was thinking exactly the same.

When you released the current package to NuGet, did you release it using the nupkg from the codebetter CI build? If so, we should be able to track it down.

With the move to SemVer we will be much less likely to have this situation again. We will be controlling the version manually and we should probably just label the revision in git when we do the release. I also think that when we move to a new build script we should introduce support for building with pre-release SemVer version. We could then increment the version to the next pre-release immediately after releasing.

[adamralph]

OK I think I've found it.

It seems like the last commit made before the current release was 5065f21.

Both this commit and the current release occured on 31.08.2012. The next commit to the code base on 10.09.2012. The current release is 1.7.4626.65 and the version number commited here was 1.7.4626.64 so this adds up. The CI build would have incremented the revision from 64 to 65.

I've created a tag at this revision https://github.com/adamralph/FakeItEasy/commits/1.7.4626.65.

I've also created a milestone for the 1.8 release so that we can mark all issues that are forming part of the 1.8 release with this milestone. At the same time each issue can labelled with the new labels I have created - 'enhancement', 'bug', 'breaking', etc. This should make it very easy to gather release notes to put into the nuspec metadata for the 1.8 package.

I will start checking through all the changes made since the current release and make sure there is a corresponding issue for each one, marked with correct milestone and/or labels.

[adamralph]

I've checked all the commits and we have no breaking changes so far since the 1.7.4626.65 release.

I've marked #21 as an enhancement and added it to milestone 1.8.

In the changes for #21, another bug was fixed. I've raised (and closed) #41 for that we are also reminded to add it to the 1.8 release notes.

I've also raised #42 for updating the release notes.

If I'm not mistaken, milestone 1.8 now contains all the issues that so far form part of the 1.8 release.

We should be able to close this issue if or when pull request #40 is merged. Nudge nudge ;-)

If we can close this issue, I propose that we pick up #42 and then release 1.8.0!