Version Numbering of NC-instances

šŸŽ Releases
1

I was wondering if there was any scheme that nextcloud is following by giving out releasenumbers?
ok the basic scheme is apparent
xx.yy.zz
where xx is the counter for major releases.
and so - in my understanding - yy would mark a minor release
and zz (with zzz possible) would mark bugfix-versions.

since 12.0.1 contains more than 120 bugfixes and it took you guys over 2 months to get it out it would team up (from my point of view) to be minor-release 12.1.0 rather than 12.0.1.

and it would allow you to roll out more often (you even could set up another channel like ā€œstable-bugfixesā€ or such with having xx.yy as being the future stable channel.

i meanā€¦ i donā€™t know how much more work this would mean for you. but it would have caused you less questions as ā€œwhen is 12.0.1 is gonna come outā€ and such.

@Jospoortvliet iā€™m adressing you here in particular since you are kind of a spokesman of nextcloudā€¦ :wink: but as this one here isnā€™t only intended to be for Jos I guess everyone could take part in itā€¦

iā€™m looking forward getting to know about your definitions of version-numbering :sunny:

2

He, not a bad idea seeing indeed how big 12.0.1 has turned out to be. But weā€™d have to discuss this a bit. I personally think we should drop the .0 part, making it 12.1 12.2 etc, only major/minor number. But pfff :smiley:

For how, ā€˜historical reasonsā€™, we stick with 12 - 13 - 14 and have bugfixes with an extra 0. This also makes migration from ownCloud a bit easierā€¦

3

so i think iā€™m gonna hear again from you about this at some point :wink:
and of course I know that this one hasnā€™t a high priority and so it could take a while.:crazy_face:

4

Versioning scheme is perfectly fine for semver. Since 12.0.1 doesnt add new features but only bug fix releases itā€™s the correct choice. Dropping the last 0 in 12.0.0 would make things incompatible with semver and break the store api :slight_smile:

So tl;dr you can say Nextcloud follows semver

5

ok, i see the logic behind the chosen versioning scheme.

though i think having a stable but nevertheless buggy major version (due to a buggy 3rd-party software afaik) shouldnā€™t be ending up in letting unexperienced users down for 3 months to wait for a bugfix version. updating should have been done faster. imho. evenmoreso if you have an upcoming new majorversion in sight, already.

but wellā€¦ things are as they are. but maybe we could learn from this to make it better next time?

btw @BernhardPosselt would v13 really be a major version (with incompatible changes to the api) or more like a v12.1? :wink:

6

The very first release of products is often a bit buggy and if you want to rely on very stable software in production, I would wait for the first bugfix release.

I donā€™t know the exact reasons, but it general the first bugfix release comes out 4-5 weeks after the initial release. More than 2 months is indeed too long.

About the major version numbering, we had a longer discussion directly after the fork from owncloud:

Changing the numbering scheme creates a lot of confusion among users, so I think we should not do it except there are very good reasons to do so. Currently major upgrades occur when the first number changes, for user that means that they have to be more careful if the system requirements have changed, if apps are also available in the new major version and up to now, we canā€™t skip major upgrades.

7

Letā€™s say I donā€™t know of any major version that didnā€™t require newer libraries (deps), php versions or didnā€™t have minor/major app api breaks :wink:

8

@BernhardPosselt considering some complains from @brantje we need to do a better job at communicating those changes to app devsā€¦ @brantje any chance you can elaborate on what went wrong?

9

Yea, the appstore required that info.xml and database.xml are valid.
I got this error during upload:

But, it turned out that my database.xml was incorrect and not info.xml as given in the error.
Afaik there is an fix for that, not sure if itā€™s live yet.

But if things like the following change:

  • Removing an attribute
  • Changing requirements of XML
  • Changing allowed values in xml

I would prefer it to be notified on an e-mail i supply. This because i get a lot of e-mails during the day.
For this case i can setup a special e-mail account, so when a mail arrives i know i should handle fast.

2 Likes