The Scribus releases: going for 2.0, 3.0, 4.0, ...

[a.l.e]

Today, I have a suggestion concerning the future version numbers of Scribus.


TLDR: Starting from the next release, Scribus should use a simpler x.y release number schema (the next values being 2.0 and the following one 3.0) instead of the current 1.x.y one.


Up to now, Scribus has been using a versioning schema that was very common in the past:

• development starts in an odd version (like currently 1.7.0svn), and
• when the software is ready for been published in a new version a new even version is created (the next, 1.8.0, is planned for the end of the year; 1.6.0, followed by 1.6.1 and 1.6.2 came out at the beginning of this year).

The world has changed, and nowadays few software stills uses this schema (Gimp being one of them) but most just use x.y.z (Inkscape, Blender) or xxx.y (Firefox and most browswers) or flexible schemas (MacOs, Windows) without giving any special meaning to the numbers (except that, mostly, bigger is better).

And most users seem to have a hard time understanding the current Scribus version schema.

My suggestion:

• In the future each new release should increase the first number by one (so, after 1.6 there will be 2.0; it will be strange at first, but once we get to 4.0 nobody will care anymore)
• There should be no different number schema for stable and development version: once 2.0 is released, the development of 3.0 starts and when it is ready, it will be released as 3.1 (or 3.14 if there are lot of pre-releases before)
• This will also answer the question: after 1.8, should we have 1.10 or 2.0?
• And it's more environmental friendly, since we waste less numbers...
• (And, yes, we should keep 1.7 for this development cycle! No need to hurry.)

I believe that this change will simplify the communication with our actual users (even the MacPorts maintainers do not seem to understand it...)

[Nermander]

You are essentially suggesting to drop the first 1 that has been there like forever?

[a.l.e]

no, it's about dropping the third number (we have had a forth one sometimes) and increasing the first instead of the second.

but yes, we could also drop the 1. and make the next stable release scribus 7.0 or 7.1 (instead of the 1.8.0 that we would get, if we follow the current schema).

now that i think about it, your suggestion is even better and would avoid the "not so nice" 2.0 (many people associate a small revolution with the release of a 2.0 version...).
and i've already seen several people mentioning scribus 5.4 without the leading 1.

such a jump has already happened for other projects. that wouldn't something completely new.

[Nermander]

I was mainly referring to that the first 1 has been there a long time without changing, and thus it not really significant.

It's a bit like when you in homebrewing refer to the specific gravity, you usually say SG 50 when it is formally 1,050. (And you say -10 when it is rather 0,990.)

[mnawij]

I prefer the [year.month] model: 2024.4 if the release came out this month. Easy to understand.

[RodneyLee]

Using "STARDATE" would be more fun

[a.l.e]

Sadly, no reaction from Craig or Jean.

Personally, after this discussion, I'd really like to see Scribus 7.0 or 7.1 (depending on the number of alpha and beta releases...) to be the next release at the end of this year. Then 8.0svn will start as the next development branch and will be released as 8.0 or 8.1 when it's ready.

Time have changed, and almost no project uses complex version numbers.
No even / odd schema anymore, either.
It does not have to grow to the crazy numbers over hundred of Firefox and Chrome, but there is no risk to have version 50 of Scribus anytime soon...