68 Responses to “How to name the distribution releases?”

1. paul
   March 11, 2011 at 13:43 |

   The ubuntu YY.MM variation is the most clear, in my opinion. Gives a more ‘normal’ version number to a release than YYYY(-MM) would (“Version two thousand and eleven – this project is OLD!” ;)), and also gives a clear idea of when the software shipped (which the fedora method does not).

   • gumb
     March 13, 2011 at 14:14 |

     Now is the perfect opportunity to go with the Ubuntu-style numbering, since it would preserve backward compatibility (something previously stated by an oS dev as a prerequisite) and align with other major distros (not just Ubuntu but derivatives like Mint and many others) which would provide journalists with more facility to make direct distro comparisons.

     The existing old-school style provides a false reference point and despite years of trying to advise to the contrary, there are still countless lazy reviewers and journalists (even some of the most respected and well-read out there) who make the assumption that a point-zero release denotes a major update. The limitation to .3 before a major number update seems rather arbitrary. 11.4 isn’t the first .4 SUSE release (there was at least 6.4 I believe). So why not .5 or .9? It all becomes meaningless.

     Fedora-style seems nice and simple at first but things start to get confused around about now at the 15-20 mark, when the lack of any other reference just makes all their releases a bunch of numbers. Was it Fedora 46 or 44 that contained linux-kernel 4.0? Nobody will ever know.

     It hasn’t been mentioned here but the initial comments by Andreas about there being no current system seem to be at odds with what I’ve read many times previously in that it was always dictated by the needs of the enterprise product. Hence, when a new SLE was due, the major version of openSUSE was bumped in advance and the enterprise edition based off of that. With the current uncertainty about the future direction with Attachmate, I think it’s also a good time to abandon that principle.
   • pivello
     March 14, 2011 at 16:49 |

     Old school. It’s part of openSUSE’s identity, as a major distro. As already pointed out, every major distros have their own numbering system, and we have ours too.

     • Federico Lucifredi
       March 16, 2011 at 17:34 |

       Old School, I like the way it is.
2. ladislav
   March 11, 2011 at 14:00 |

   since March is in spring, July in summer, and November is in autumn

   That smacks of arrogance. There are many countries where summer is in December while many others don’t have four seasons at all. Bad idea in this Internet age.
3. Vavai
   March 11, 2011 at 14:15 |

   @Ladislav, +1

   We have 2 season here 😉

   I would vote to go with current/old school option or go with Ubuntu style with minor difference.
4. Karl Kochs
   March 11, 2011 at 14:16 |

   I would name the openSUSE Editions after german artists, like Goethe, Schiller, …
5. James
   March 11, 2011 at 14:46 |

   I would name the openSUSE Editions after my German ex girlfriends in strict alphabetical order: Angelika, Birthe, Christine…
6. Oddball
   March 11, 2011 at 15:02 |

   I did not know there were countries with no seasons!
   I also did not realize summer is in Northern or southern parts in another month, which is quiet obvious though…
   11.1,2,3, would have been most logical as it always has been that way…
   What is wrong with that anyways?
   There then only would be one .4, which would always remind at the time this issue was at hand..
   The kernels have names, why not automaticly use that name, in combination with the version number? (so with kernel changes, the name would change.
   (then there would be the struggle who would be in power to ‘invent’ the name for each kernel..)
   Some things better leave unchanged, as it mostly leads attention from what is important.
   In this case: name or version.
7. Cornelius Schumacher
   March 11, 2011 at 15:41 |

   I like the octal versioning scheme. A clever way to hide a geeky scheme behind an innocent looking number 😉

   For the voting, I would propose to go with a preference voting, e.g. http://en.wikipedia.org/wiki/Schulze_method. I think that would create better results faster than the proposed two-step procedure.
8. TheBlackCat
   March 11, 2011 at 15:58 |

   There are also potential localization issues when using the season version, such as when doing searches online.

   The problems with the current numbering system are that:
   1. A lot of people seem to dismiss the version numbering just marketing, and I think having openSUSE’s decisions discussed in this manner casts it in a negative light. It also seems to rub off on other projects like KDE where numbering is not arbitrary.

   2. We waste some of the very limited time people have available on this discussion, time that could be better used for more substantial issues.

   So I think, considering that for openSUSE at least this discussion is entirely arbitrary, I think one of the date-based schemes makes the most sense. There are issues with other cultures that use different calendars, but the Gregorian calendar seems to be widely understood.

   I don’t think the octal is good for 2 reasons:
   1. I think it will confuse people

   2. I think it might come across as arrogant to non-tech savvy users.

   So that leaves two options amongst those discussed:

   1. date-based
   2. consecutive numbering

   Each has some additional questions:

   1. date-based:
   1a. How many digits for the year?
   1b. Month number or release number? (i.e. is the fall release 2011 2 or 2011 11)
   1c. What is the seperator? (2011.1, 2011-1, 2011:1, etc.)

   2. Consecutive numbering
   2a. How many decimal places, if any?
   2b. If any decimals, at what fixed number do we roll over to the next?

   I am concerned with using decimal places in a consecutive numbering system, because I am afraid the temptation to violate the numbering rules and bump it arbitrarily at what developers consider to be a “big” release might be too much.

   I am in favor of the date-based system personally, for these reasons:
   1. It is easier to keep track of how long ago you installed it
   2. It is easier to keep track of when end-of-life is.
   3. If we go with year+month, it is easier to keep track of when the next version is coming out

   Disadvantages:
   1. It might seem somewhat impersonal
   2. If we go with year+month, a change in the release date could potentially change the version number, and I don’t know what sort of problems that might cause
9. GaLaGaNN
   March 11, 2011 at 18:59 |

   “Old school” !!!
10. Rodion
    March 11, 2011 at 19:09 |

    Digits are for machines, OS capabilities are for people…
    It would be better if developers left it current. “xx.x” model is a perfect way to recognize openSUSE. It is also a good idea to increase the 1-st number only when some grand changes are to be made in next release.
11. Carlos E. R.
    March 11, 2011 at 21:15 |

    I like any variation of year.counter, where year can be 2 or 4 digits, and counter is 1 based, not 0 based.

    The octal version needs some explanation here, so I haven’t considered it.
12. sat
    March 11, 2011 at 21:30 |

    Oh no! Don’t touch current version numbering.
    Old school is best for openSUSE.
13. petyanamlt
    March 11, 2011 at 22:22 |

    1 “Old school”: The same we do right now but let’s decide when tochange the right number: we count it always until 3.
    Next release is 12.0.
    Following releases: 12.1, 12.2, 12.3, 13.0
14. 101010
    March 11, 2011 at 22:50 |

    7.
15. hron84
    March 12, 2011 at 03:11 |

    I recommend a Gentoo-like numbering: YY.C, where the C is a version counter based on zero. So, the next year first release should be 12.0, then 12.1, etc. In current year, i can recommend continue counting (11.5, 11.6) to avoid version number collision.

    I think the YY.MM based counting is not a best option. When two people talks about Ubuntu, usually says codenames, not version numbers, as the release date is not a best-known thing related to a linux distribution. E.g. without wiki, anybody can tell when 10.0 released exactly? Ok, some fans can do it, but this is not too common thing.

    the four number-versioning (YYYY.C or YYYY.MM) is too long. If somebody uses openSuSE it knowns its version numbers are 4 character long. And – last but not least – it will be too big bump from 11 to 2011).
16. SIE
    March 12, 2011 at 08:22 |

    Old school only
17. Golos
    March 12, 2011 at 09:17 |

    “Ubuntu style”: YY.MM Is Nice!!! 🙂 OpenSUSE 11.11 😉
18. Sultan
    March 12, 2011 at 09:37 |

    “Old school /Mandriva variation”: YY.counter (2 digit year, counter starts at zero)
19. ferhiord
    March 12, 2011 at 11:47 |

    “Old school” or “Old school/Mandriva variation”
20. vespas
    March 12, 2011 at 13:33 |

    I vote for “Old school/Mandriva variation”. It is better than Ubuntu because you don’t have to know if there was a previous release that year to make sense of the numbers.
21. Pavlinux
    March 12, 2011 at 17:38 |

    OpenSuse MMXII
    OpenSuse MMXII-I
    OpenSuse MMXII-II

    или

    OpenSuse XII
    OpenSuse XII-I
    OpenSuse XII-II

    OpenSuse MMXIII или OpenSuse XIII
    …
    OpenSuse MMXIV
    OpenSuse MMXV

    🙂
22. Pavlinux
    March 12, 2011 at 17:44 |

    OpenSuSE 2.6.37.3
    OpenSuSE 2.6.38
    OpenSuSE 2.6.38.5
    OpenSuSE 2.6.38.7
    …
    Well, you understand?

    • jrdls
      March 15, 2011 at 15:09 |

      that’s original, that is to name the opensuse releases after the kernel used. I think it’s worth considering.

      • Kalle Anka
        March 16, 2011 at 21:58 |

        So what if openSUSE goes the way of Debian and includes other kernels such as kFreeBSD and eventually the Hurd?
23. Pavlinux
    March 12, 2011 at 18:00 |

    OpenSuSE 12
    OpenSuSE 12. define #1
    OpenSuSE 12. declare №2
    OpenSuSE 12. call 3
24. Ansus
    March 12, 2011 at 19:47 |

    I suggest to keep the major number until a new version of Gnome or KDE is released. Thus the next release should be 12.0 (because of Gnome 3), and then 12.x until KDE 5 or Gnome 4 is released. This scheme allows to quickly figure out which releases more or less compatible with each other in regards of third-party applications.
25. TomA
    March 12, 2011 at 22:15 |

    Call me a traditionalist, but I like the current numbering
    scheme, though it would be nice to have distinctions between
    what number changed when. So, I prefer option 1.

    Second choice is the Fedora scheme.

    The date based schemes are ok, but I don’t find it all that
    useful that the numbers are based on dates. If all distros
    used date-based schemes, it would make it easier to establish
    the relationship between any two distro releases, but otherwise…
26. Dean
    March 13, 2011 at 00:37 |

    Old school SuSE. There was absolutely no reason for it to change. The old versioning scheme served SuSE for years. This topic is looking for a solution for which there is no problem.
27. Maxim
    March 14, 2011 at 05:27 |

    Old school.
28. Maxim
    March 14, 2011 at 05:51 |

    I think the best idea is make Long Term Support (openSUSE LTS) releases every two years. Many people requests this feature!

    In that case we can use current naming scheme in simple and convenient way: just increase major version number when release new openSUSE LTS. The 8-month development cycle serves this perfectly!

    Result: 12.0 LTS (November, 2011), 12.1 (July, 2012), 12.2 (March, 2013), 13.0 LTS (November, 2013), 13.1 (July, 2014) and so on.

    It’s very simple to remeber that every two years openSUSE has the LTS release in November and each time it is marked by major version number increase.

    • Gerry
      March 14, 2011 at 12:37 |

      @macias

      Best suggestion so far. Old school with purpose.

      • Gerry
        March 14, 2011 at 12:39 |

        oops, sorry Maxim
    • JirkaZ
      March 15, 2011 at 13:57 |

      Old school with a purpose. This is the best idea for me, too.
    • jik
      March 15, 2011 at 20:33 |

      I think, that OpenSUSE needs LTS version – Old school with purpose. But I would prefer to think, that changing major number means a big change of “innards”… and is not suitable as LTS. Version with zero is technology edge and after it comes stabilized version “one” – LTS. My suggestion is:
      12.0 – technology edge
      12.1 – stabilized – LTS
      12.2, 12.3 – conservative development
      13.0 – technology edge
      13.1 – LTS…
29. seleko
    March 14, 2011 at 08:55 |

    Old school, but should be strictly defined the number of minor builds, imo.
30. macias
    March 14, 2011 at 09:17 |

    Mandriva old school — YY.## with minor correction — starting with 1

    Reasons:
    * it is very unlikely there will be no release in a given year
    * the order is kept
    * by just looking at number you know which release it is (Ubuntu is similar, but looking at 10.10 you cannot tell if it is 10th release in this year, second, or maybe 20th)
    * and reason for correction — for release at January it would really look odd, to have version 12.0 released at 12-1, since months are numbered starting with 1, the versions should start with 1 too

    KISS.
31. vrtz
    March 14, 2011 at 12:43 |

    Just keep it “old school”. As Dean already pointed out, there is no problem.
32. Anamezon
    March 14, 2011 at 13:35 |

    What I would like most is to see next OpenSUSE labelled following the “Ubuntu style” fashion – YYYY-MM (4 digit year, 2 digit month) with the addition of X.Y.Z. kernel number (e.g. 2011-11/2.6.??); to me it seems pretty informative and you won’t have to go back and figure out “oh, which kernel was out in Nov 2011? …
    on second thought, I’m rolling on Tumbleweed, so that ain’t such a big issue …
33. Kevin
    March 14, 2011 at 14:56 |

    YYYY.2-bit

    2012.00
    2012.01 (may be used)
    2012.10 (likely not used)
    2012.11 (likely not used)
    2013.00
34. a23d56
    March 14, 2011 at 15:44 |

    0.000 thru 9.999

    each release +0.001

    Next release starts at 0.000 to start the new scheme.
35. kzarog
    March 14, 2011 at 15:46 |

    How about the “Matlab convention” YYYYrelease_letter. I’ve always thought it was the simplest and nicest convention out there. For example, next releases will be (if starting from the November release)

    openSUSE 2011b
    openSUSE 2012a
    openSUSE 2012b
    openSUSE 2013a
    openSUSE 2013b

    and so on. If not the Matlab convention, a YYYY.MM should be cool. The old convention is nice, but doesn’t help this great distro in terms of “coolness”. And please, please don’t go for the octal one. Linux is way too geeky as it is!
36. a23d56
    March 14, 2011 at 15:55 |

    Anno Domini years have religious connotations. 0.000 thru 9.999 would be simple, mathematically precise, politically neutral, and distinctly unique among distros.
37. Steven White
    March 14, 2011 at 16:21 |

    I always assumed that the major number change (10, 11, etc) represented some major change (new kernel, new Gnome/KDE), and that the minor numbers (x.1, x.2, x.3, etc.) represented minor improvements and “sustained engineering” fixes. With that in mind, I never purchased x.0, and lately have been waiting until x.3 to jump, in the hope that things will work a bit better.

    Before this policy, I purchased 9.1, then 10.1, and it always seemed that 9.3 and 10.3 were the “better” versions. I actually had a phone conversation with a person from Novell, who said something along the lines of, well, they rushed 10.1 out the door a little soon and 10.3 had more of what I wanted (whatever it was that prompted that phone call; I forget the details).

    In addition, I always thought that the versions counted to 3 (10.1, 10.2, 10.3, 11.0, etc.) I was all ready to purchase 11.3 when I heard of the coming of 11.4. Now I am thinking about buying 11.4 and what is on the horizon? 11.5. This is very confusing.

    I am not a computer expert, just a guy who likes to use OpenSUSE and is computer-literate enough to be able to install it himself and do basic troubleshooting. I don’t care what the numbering scheme is, but I would like to have a clear idea of what it means.

    • houghi
      March 16, 2011 at 17:33 |

      The current numbering is confusing as many people think that*.0 is beta where it is just linked around a new version of SUSE.

      So what will be the impact on the SLE numbering? I would suggest that there still would be some linking between the two. Otherwise you will get something like “openSUSE 2018.04 is a bit the same as SLE 14″

      So if SLE won’t follow, stay with old school, where I think *.0 used to be the version before SLE * and then the once after it where called *.1, *.2, *.3 and even *.4 with some versions.

      My preference would be YYYY.MM so 2011.11

      Or go geeky all the way and use ddate.
      houghi@penne : ddate +”%Y %B” 17 11 2011
      3177 The Aftermath
38. a23d56
    March 14, 2011 at 16:34 |

    Steven you’re right. Who decides when to bump to 12.0? And why? It’s arbitrary and misleading.

    I don’t think my proposal will succeed though. People like copycat ideas already familiar to them. It’s hard to make bold changes.
39. Jon Scobie
    March 14, 2011 at 16:52 |

    Hex or binary. Gotta be the way to go 🙂
40. Martin
    March 14, 2011 at 19:26 |

    Hi, I am an OpenSUSE 11.3 user.

    First preference:

    “Seasons”: “Season YYYY” since March is in spring, July in summer, and November is in autumn.
    Next release is: Autumn 2011
    Following releases: Summer 2012, Spring 2013, Autumn 2013, Summer 2014

    Secondary preference:

    “Mandriva style”: YYYY.counter (4 digit year, counter starts a 0)
    Next release is: 2011.1
    Following releases: 2012.0, 2013.0, 2013.1, 2014.0, 2015.1

    The second option is a bit weird if we receive a major version update every 8 months. Because a distribution ending with .1 or .2 mostly indicates bugfixes (see KDE 4.6.0, KDE 4.6.1, KDE 4.6.2, KDE 4.6.3, KDE 4.6.4).

    Best option:

    Use Mandriva style, but switch to a yearly release cycle to support that, with only bugfixes and application upgrades in between.

    So in May 2012 release OpenSUSE 2012 with the lastest kernel and the latest application versions.

    And in November 2012 release OpenSUSE 2012.1 with the same kernel, but with the latest KDE version, with the lastest application packages and with all bugfixes.

    That would also make for an even more solid distro. Which is a key selling point in my opinion for the OpenSUSE Distribution.

    I choose May / November because KDE releases January / July and this gives KDE a couple of months to fix the major issues.
41. ken_yap
    March 14, 2011 at 22:30 |

    4. Old school/Mandriva i.e. 11.5 next. Ideal time to change to make the major number represent the year.
42. Zorklat
    March 15, 2011 at 00:51 |

    I like the “Old School With A Purpose” scheme, i.e., “12.0 LTS (November, 2011), 12.1 (July, 2012), 12.2 (March, 2013), 13.0 LTS (November, 2013), 13.1 (July, 2014) and so on.”
43. neoKore
    March 15, 2011 at 11:23 |

    I think that OldSchool or Mandriva+OldSchool would be fine. Other styles can be weird for some users or countries. So I think that is better continue with the identity of openSuSE using the OldSchool style, or improve it using short year with counter, that is clear too to identify the last version, but doesn’t make “jumps” like ubuntu for newbies that maybe don’t know that after 10.10 goes 11.04.

    Sorry for my english.
44. Courage
    March 15, 2011 at 13:24 |

    “Mandriva style”: YYYY.counter (4 digit year, counter starts a 0)
    Next release is: 2011.1
    Following releases: 2012.0, 2013.0, 2013.1, 2014.0, 2015.1
45. Spyhawk
    March 15, 2011 at 16:15 |

    I’d definely choose the “Arch Linux” way of doing it, ie 2010.05 for their last release.

    YYYY.MM
46. some_hockey_nut
    March 15, 2011 at 17:29 |

    As was previously suggested by Maxim, the old school way with a purpose: have an LTS (Long Term Support Release_ every 2 years, and use the current numbering scheme with the major version number changing for each LTS. Each non-LTS would increment the minor version number.
47. 1linuxfreak
    March 15, 2011 at 19:01 |

    My suggestion on the openSUSE group was pointing out the old school way to .3 then change and then suggested if we need a new scheme then do 2011 version 5 , 2011v.5 for short still maintaining version numbering along with year of conception .
    My $.02
48. corn
    March 16, 2011 at 02:31 |

    Oh please use a binary based on the Chinese calendar to show how LeeT we are.

    Next release…. 100100100101.100.FFFF
49. vladano
    March 16, 2011 at 07:44 |

    The best is “Old school/Mandriva variation”, or only “mandriva variation”, i like to know how old that system is. Will be any voting system?
50. Shiba
    March 16, 2011 at 10:05 |

    Seasons for me.
51. jik
    March 16, 2011 at 10:23 |

    My yesterday’s suggestion was very “quick”, now I try describe it better:
    I think, that major number represent concept features and minor number conservative development in concept’s border. It means, that major release locks up main concept of system, compiler, main libraries, concept of packages etc (flexible). Minor releases bring to bugfixes, newer version of packages, completing translations … without any massive distribution development and with easy and smooth distribution update. I think, better is debate about “remastering” of previous version of distribution.
    It is a good idea, that the new major releases (12.0 -> 13.0) will be every 2 years. The first minor release (12.1) will be 2-4 month after 12.0 and the other minor releases 8 month after previous release (12.2 and 12.3). Support time for major release is only short with easy migration to the first minor release (which is LTS), the other releases has standadr time support:
    .0 – technology edge and not extra robust version – for enthusiast
    .1 – LTS version (I accept also paid extended support); for servers and also for general use
    .2 and .3 – standard period support; for general use
52. jik
    March 16, 2011 at 12:06 |

    I think I would like to change the way my birthdays go…. next birthday I am 2011.46
53. Picajoso
    March 16, 2011 at 14:39 |

    That’s an interesting change. I’m the editor of MuyLinux, a Linux blog in spanish, and I’ve made a little poll there (one of the most important blogs about Linux in Spanish globally) and maybe this data could be useful for you. The post URL is:

    http://www.muylinux.com/2011/03/15/%C2%BFcambio-de-numeracion-en-opensuse/

    Good luck with the decision!
54. Matt
    March 16, 2011 at 16:03 |

    Old school, don’t change it.
55. Richard
    March 16, 2011 at 22:14 |

    Old school served us well for over a very long time already, what is it 15 years or more!
56. Italia F.
    March 21, 2011 at 13:52 |

    I prefer the Ubuntu style, simple and very clear!
57. marvin
    March 22, 2011 at 10:33 |

    I know it’s a bit late, but I have another naming scheeme based on numbers (start counting at 13, 14, … and so on) and a name based on the 18 penguin species (in alphabetical order), e.g the next verison would be called

    openSUSE 13 (Adeline)
    openSUSE 14 (African)
    …
58. Drew
    March 22, 2011 at 11:22 |

    I like the version numbering the way it is. I hope we continue on with our “old school” release numbering for many, many years to come.