Mailinglist Archive: opensuse-project (207 mails)

< Previous Next >
Re: [opensuse-project] Code names
  • From: Mark V <mvyver@xxxxxxxxx>
  • Date: Tue, 5 May 2009 10:15:52 +1000
  • Message-id: <389c43e40905041715l234d1569se53f292669552064@xxxxxxxxxxxxxx>
Allow me to argue against colors once more...

On Tue, May 5, 2009 at 5:27 AM, Pavol Rusnak <prusnak@xxxxxxx> wrote:
Andrew Wafaa wrote:
if we go for a code name use it only as a pet name rather than the primary

As far I understood it from the thread, people are suggesting to use
code names as an extension to the (unchanged) numbering scheme.


11.2 Amaranth
11.3 Burgundy
12.0 Crimson
12.1 Denim
12.2 Emerald
12.3 Fuchsia
... you get the idea ... :-)

This might send a signal to the community that:

* each openSUSE release is individual & unique

Then either the <Major_num>.<Minor_num> or the <name> seems redundant.
Neither version number nor name tell me anyhting useful. Certainly
not when I should give the release up and move on.

* major changes do not happen only in x.0 releases

Then why do we distinguish minor from major releases? If this really
is the case I think many users, and not just novices, will be

My impression is the convention that minor numbers indicate minor
changes is so ingrained the project/community has a responsibility to
stop using minor number changes to indicate major changes.
Further more if 10.3->11.0 means no more than 10.1->10.2 then I'd also
argue we are misleading 'novices' or even sophisticated outsiders.

This suggests moving to a identity naming scheme that abandons
incremental numbering is imperative.

* x.0 is not less mature than the others

Then why do we insist on using such numbering?

* x.1,2,3 are not just updates to the previous ones

Then really these minor number increments seem misleading given what I
understand is the information 'average' users impute from these

OK so I'm repeating myself....

Why is using the end-of-life YY-MM not:
- informative about an important piece of information?
- indicative of freshness? That is, it seems clear that 09-11 is an
older release than 10-12

Granted there will be some explaining to do, but the benefits are:
- You can still (if I understand openSUSE release/support policy
correctly) tell which release is newer than the other. The color
scheme does not allow this, so you would still need numbering.
Numbering detail that is meaningless - all noise no signal.
- You clearly indicate when a release has expired. Reading an email
or forum thread about openSUSE 12-01 (or 12:01 to disambiguate the
legacy numbering convention) in 2013 means I know this information is
likely either built in to my current 'alive' release or irrelevant.

Some issues are:
- What should the YY and MM separator be? It probably should not be
'.' to avoid confusion with the current numbering scheme.
- Is it possible that end-of-life dates might leapfrog, e.g. 13-07 is
older than 13-10. I understand that this might happen with Ubuntu's
LTS release/support policy but I thought the openSUSE release/support
policy ruled this scenario out... correct?

No one has raised an objection to end-of-life YY-MM naming.
I agree that it is a (very?) different idea.
Is it really that stupid an idea, as to be axiomatically a bad idea :)
Some reasons it is a bad (counter-productive) idea are....


Best Regards / S pozdravom,

Pavol RUSNAK                                       SUSE LINUX, s.r.o
Package Maintainer                                Lihovarska 1060/12
PGP 0xA6917144                                     19000 Praha 9, CR
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx

To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx

< Previous Next >