Version Numbering of NC-instances

I was wondering if there was any scheme that nextcloud is following by giving out releasenumbers?
ok the basic scheme is apparent
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:

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…

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:

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

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:

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.

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:

@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?

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.