Version number schema

Another question is: Will we start with 1, 9 (…for compatibility reasons) or a number completely different like 42 as openSUSE has done with their Leap Release :stuck_out_tongue_winking_eye:

I’m not in favour of names. I can never remember which Mac OS X name refers to which version.

I don’t mind the “simple” 8.0, 8.1, 8.2, 9.0 version numbers, but referring back to the OP - upgrades should be made easier. It should be possible to upgrade from 8.0 to 8.2 without having to upgrade to 8.1 first. Even better if we could upgrade from 8.0 to 9.0 without going through intermediary steps.

is there no way to update automatically from 8.0 to 8.2? I mean You say nextcloud to update from 8.0 to 8.2 and internally it installs 8.1 automatically and in the last step it installs 8.2

Currently not. But @frank has told us in the Hangout yesterday, that the update experience will be improved soon :sunny:

1 Like

In the case of NC, semantic versioning and browser numbering means the same thing, because each quarterly release is a major upgrade. I don’t think that will change any time soon as the product still needs to mature.

So for 2016, we could have NC 10 in July and then 11 in November. Patches would be released as 10.0.1, 10.0.2, etc.
I don’t think it’s worth messing with minor releases at this stage.

Hi everyone,

I just wanted to gather some feedback on the Android App version number we should choose for the inital release. The server side went for 9 which matches the oC version.

As for the Android app a user usually doesn’t see the version number so we could choose whatever number we want which would mean we either go for 1.0.0 or 2.0.1 (since it is based on the upcoming oC 2.0.1 Android app).

Any preferences? The versions will divide quite fast anyways, so either one is fine!

I would not bound it in any way to the server version number to not confuse users about if the app is compatible with a given server version number.

So 1.0.0 or 2.0.1 then? :smiley:

I prefer 1.0.0 because it is the first nextcloud release.

So looping in @tobiasKaminsky for the version name/number :slight_smile:

1.0.0 is fine for me.
Are we gonna use semantic versioning as well?

I think semantic versioning would be easier for developers since we use it in nextcloud, too.

Yes for semantic versioning and 1.0.0

1 Like

I’d agree. Semantic versioning, starting at Nextcloud 1.0

The Server will start with 9.0.0 and the Android app will start at 1.0.0 :rocket:

1 Like

mh but why? It is imho the first release of nextcloud so are there any arguments to release it as 9.0?

Personally, I’d be fine with starting Nextcloud with either 1.0 (for simplicity) or 9.0 (to make it easy for ownClouders to understand what the equivalent is).

If we go with release names though (which I like the idea of), I’d suggest we carefully consider the naming schema from a marketing perspective. Apple did this well, naming their releases after big cats, for the impression of power, strength and speed. Google did this well with their desert naming scheme, as, well, who doesn’t look forward to desert? Ubuntu, well… let’s just not go down any similar route to that hideous, random, incomprehensible, unthoughtout mess of a naming scheme.

Names of whistleblowers is a good start, but the previous poster who suggested that it wouldn’t match many enterprise users. If looking for a naming schema, I would ask, what sort of feelings are most of our users looking for? What category of things embody and create those feelings well?

I would suggest that our users are looking for feelings of privacy, security, freedom and community.

Looking forward to desert? or dessert? :slight_smile:

As someone who grew up in a desert state, I can unequivocally say… desserts are far more fun. :smile:

+1 for Semantic versioning throughout the Nc universe.

1 Like