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.
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.
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
Second it! This scheme was just an obviously bad decision.
Seconded by me as well.
+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.
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.
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â
Itâs just an idea, i think every other concept would work. For example greek gods or game of thrones characters.
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 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
City names are an good idea in my opinion âŠwould be nice to call the branches berlin
or tokyo
instead of stable1
or stable1.2
âŠwe could take the city of the last contributor conference (if there is one ) for example.
What about take the Version number schema of Ubuntu? YY.MM (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.
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.
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.
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.
Semantic versioning is a great standard to use.