Always have 3 parts in the XWiki Standard version

Development
1

Hi everyone,

We currently have a not very consistent situation with the XWiki Standard versioning:

  • first version of a branch has 2 parts (14.10)
  • then bugfix versions have 3 parts (14.10.1)

It can be confusing to some which struggle to know what exactly “14.10” means (the 14.10.x branch or the 14.10 first final version) and it’s getting worse with the images on docker hub: the image with label “14.10” is actually the version “14.10.19” and if you want the “14.10” version you ask for “14.10.0” which is not something that exist in terms of XWiki tags.

I would like to propose, starting with the 16.x branch to simplify all that and always have 3 parts in final versions, meaning that the first version of the 16.0.x branch will be named “16.0.0”. This means the first RC will be “16.0.0-rc-1” and we’ll need to change the current version we have in master to “16.0.0-SNAPSHOT” (as the SNAPSHOT version is supposed to be consistent with the next final version in the branch).

WDYT ?

Here is my +1.

2

+1

3

+0

Thanks,
Marius

4

+1, thank you!

5

+1 thanks

6

+0 thanks.

I think it’s pretty common to not specify the bugfix version when it’s not a bugfix version and I’ve never liked too much projects that did. Oracle is the “worst” on this, see About Oracle Database Release Numbers :wink:

Note that our dockerhub tags are something else and they don’t have an equivalent in XWiki (except when using ranges in Maven). The way we use tags in dockerhub means “latest version of that branch”. So 14 is the latest version of the 14 cycle, 14.10 is the latest version of 14.10 (e.g. 14.10.20) and 14.10.20 is the latest version of 14.10.20 (i.e. 14.10.20 since we don’t release sub bugfix releases). But indeed, the new proposed scheme would remove some possible confusion.

In any case, even if I’m not a big fan of it, I don’t see any problem of changing the versioning, hence my +0.

Thanks!

7

Note that as a bonus, if this proposal passes, I locally have a new version of the release script with much more accurate default answers to the various next SNAPSHOT versions questions :wink:

2 Likes
8

I think this can be raised as well for contrib projects, as this could become quickly a habit.

+1
Thanks

9

yes if we do this we do it all over the board (contrib follows the xwiki.org dev practices anyway).

10

Whatever the outcome, it would be nice to have the same conventions for XWiki SAS projects (including pro / paid apps). I’m constantly switching between contrib and xwiki sas projects and subtle differences like this are a bit of a pain and a source of mistakes.

11

5 +1
2 +0

The new format is adopted. I updated the following accordingly:

2 Likes