SemVer - is it working for the project?

[Lee Kelleher]

In the recent topic "MVC 5 + WebApi 2", there was some discussion around Semantic Versioning - whether it helps or hinders core development and is it compatible with marketing ideologies.

My simple question is, after adhering to it for the past few years - is SemVer working out for the project?

[Shannon Deminick]

This is my personal opinion:

I think the idea of Semver is great, and it's a great thing to strive to achieve but a 'breaking change' needs to be defined by the application, not by a generic technical definition. By technical definition, this could be literally any change.. for example:

This is why we have this page setup: http://our.umbraco.org/documentation/Development-Guidelines/breaking-changes , because if weren't allowed to 'break' a few of those things, then this project would be impossible to progress further. 

If there are breaking changes introduced which are outside of what we deem a non-breaking change during for a mid-major-version release, then documentation is critical. This would only happen at a minor release, such as 7.3, not in a patch release like 7.2.2. 

There are actually some breaking changes that will be in 7.3: http://our.umbraco.org/contribute/releases/730 but since they shouldn't affect many people, we've decided that it's worth the change. 

In my opinion, like what is mentioned in this discussion: https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e is that version numbers need to cater for *both* the developer and for where the project currently is, and in order to do that you cannot follow guidelines based around what a generic technical definition of a breaking change is.

I actually believe that the way we are handling versions is working quite well. There might be a breaking change in a minor version release but we'll try as best as we can to not have them. However, when the necessity/benefit out-weighs the minority of people affected, then it's worth doing - and there will be information about it in the release notes.

[Andy Butland]

Having chipped in on the referenced discussion, for me the approach Shannon outlined is a very sensible approach to take and one I'm quite happy with as a developer of Umbraco solutions.  I feel adherence to SemVer would only become a problem if in strictly enforcing it meant that useful features that were otherwise ready for release were held back for a lengthy period of time.  It seems that's not happening.  Rather where necessary - and on minor point releases, with documentation - small but technically breaking changes are permitted, which sounds like a good, pragmatic approach.

Andy

[sniffdk]

+1 to the way you guys are handling versions. 

Keeping breaking changes in minor releases to a minimum though allowing a few here and there, when it doesn't affect the majority of people.

And yes, personally, I do think SemVer is working very well for Umbraco. As long as SemVer is used as guidance, as I believe it is now, and not a strict set of unbreakable rules.

[Sjors Pals]

I thought Umbraco was already using SemVer?

Must say that we lately had a lot of issues with minor upgrades, lately we did a V6 upgrade and now a lot of Editor Macros are not working anymore. 

Research showed that it's not allowed anymore to use certain characters in Macro aliasses, we have to fix this with a very risky Database upgrade.

Another breaking change was that using the same applicationID on a load balanced setup did not work anymore.

Op woensdag 21 januari 2015 13:37:54 UTC+1 schreef Lee Kelleher: