Version number schema

By @bjoern:

We should re-consider how we name our versions. People just don’t get that 8.1 and 8.2 are different major versions and that you can’t update from 8.0 to 8.2.

9 Likes

I only could just second that. It was very rarely the case that a user understood the difference and nearly everybody spoke of the ownCloud 8 version even if it was 8.2 :wink:

1 Like

Second it! This scheme was just an obviously bad decision.

Seconded by me as well.

So maybe finally doing proper semantic versioning is in order? http://semver.org

14 Likes

+1 for semver.org and thinking in terms of breaking.feature.fix is also nice to have in the back of our heads.

The idea is to never break hard and always have a transition phase of 3 years … so breaking will at most increase every 3 years but only for some few APIs. I guess this “breaking” is more something for a library instead of a whole application.

1 Like

In my opinion, if there is a migration available and it does not break current apps, then it’s not breaking. But as soon as it breaks apps and current functionality, it’s breaking.

1 Like

also +1 for semver.org also with the view of (potentially)breaking.feature.fix
imho you need to be able to break or your maintanance costs will go through the ruff at some point.

Not sure if it needs to be 3 years I would rather go for a deprecation schema as in
Mayor Version X deprecates an API
Mayor Version X+1 still deprecated the API
Mayor Version X+2 removed the API

This would lead to probably a 2 years phase before applications would need to be updated to the latest API which should be fine imho. But looking at Enterprise I get the >=3 years value.

If you want to increase the recognition value of a major releases, you could name it like a thing everyone know. Like Google does with Android.

Nextcloud is for protecting your private data so maybe you can name the first version “nextcloud snowden” :stuck_out_tongue:
It’s just an idea, i think every other concept would work. For example greek gods or game of thrones characters.

1 Like

Personally, I can never remember which Ubuntu Code name belongs to which version. Or which is the current one. After too many Dappers, and Edgy, Intrepid and what not i don’t even remember which were around :slight_smile: But a combination, might just work, Android also has it’s version numbers.

Yes I think a combination is required. But whether you can remember which version belongs to which name is related to the name itself. It should be something most of the people know. Something to eat, to drink, or maybe last names.

Edit: I don’t know whether it is possible but I as far as I know there is no software which is using city names for versioning. Something like “Nextcloud 1.0 Berlin” or “Nextcloud 1.0 Tokyo”. Using this, in a discussion everyone will know which version is meant someone is talking about.

I think this would scare off enterprise customers… It would be very political :confused:

City names are an good idea in my opinion :wink: …would be nice to call the branches berlin or tokyo instead of stable1 or stable1.2 :wink: …we could take the city of the last contributor conference (if there is one :sweat_smile:) for example.

What about take the Version number schema of Ubuntu? YY.MM :thinking: (e.g. 16.06)

I’m for browser numbers. Just increase at each major release. No confusion.
App X is compatible with Nextcloud 37, App Y with NC 41.
Adding names just brings confusion when you have more than 1 release a year.

2 Likes

That’s true, but I think it’s better to have one major release a year. All other changes should be .xx releases. So you have enough time to test big features and improve them.

That didn’t work with ownCloud and the reason the core team switched to quarterly releases. You don’t want to have to wait a year to have a new API if the project has the resources to deliver it in a couple of months.

3 Likes

Most certainly what @oparoz said. You need to release features as quick as possible once they are done. holding code for a year “just because” is a waste of resources.

1 Like

This is exactly what GNOME is doing since their last conference actually. (Starting with »Gothenburg«.)

I would say we either do Semantic Versioning or the simple&easy numbering as @oparoz mentioned.

Personally my vote is also for semver.org or simple numbering á la FF

Semantic versioning is a great standard to use.

1 Like