Home Home > 2011 > 03 > 11 > How to name the distribution releases?
Sign up | Login

How to name the distribution releases?

March 11th, 2011 by

We had this week a discussion on IRC on how to name the next release and I took the action item to do a poll on connect.opensuse.org now to help us solve the naming of openSUSE distribution releases. I’ve started earlier today a discussion on the opensuse-project list and already incorporated some comments I received in this text.

openSUSE does not have a major and minor numbering, even if it seems so. There is right now no difference in any way between what we would do for openSUSE 11.4 or 12.0 – and no sense to speak about openSUSE 11 or openSUSE 11 family. We also have no process on how to name the next release (when to increase which parts of the number).

Here are some options, if I miss some, please tell me and I will then soon setup a poll. I’m listening the next version we would use as well as how the following would be called as an example. Remember we have releases every 8 months, so the next releases will be in:
November 2011, July 2012, March 2013, November 2013, July 2014, March 2015.

Here are the options I collected so far:

  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
  2. “Fedora style”: Just integers.
    Next release is: 12
    Following release: 13, 14, 15
  3. “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
  4. “Old school /Mandriva variation”: YY.counter (2 digit year, counter starts at zero)
    Next release is: 11.5 (otherwise this won’t work)
    Following releases: 12.0, 13.0, 13.1, 14.0, 15.1
  5. “Ubuntu style”: YY.MM (2 digit year, 2 digit month)
    Next release is: 11.11
    Following releases: 12.07, 13.03, 13.11, 14.07, 15.03
  6. “Ubuntu style variation”: YYYY-MM (4 digit year, 2 digit month)
    Next release is: 2011-11
    Following releases are: 2012-07, 2013-03, 2013-11, 2014-07, 2015-03
  7. “octal”: Coolo came up with calling the next release “o 12″ and then proposed to go octal (so 012). We decided to start with 012 even if that 10 in decimal.
    Next release is: 012
    Following releases: 013, 014, 015, 016, 017, 020
  8. “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

During the last rounds of discussions about the versioning scheme, the following wishes have been distilled:

  • It must be clear which release is newer
  • It must be clear how to the next release is called, we need an easy algorithm

Coolo suggested to do the poll in two rounds: first list all – even obscure – options that have been proposed and in the next round only include those that got
more than 80% of the winner.  Of course if there is only one, the second round can be removed. The first round you would be able to tick every option you like, the second one only tick your favorite.

I’m collecting proposals now until end of Monday, 14th of March.

Both comments and pings are currently closed.

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

  1. paul

    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

      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

      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.

  2. 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. @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. I would name the openSUSE Editions after german artists, like Goethe, Schiller, …

  5. James

    I would name the openSUSE Editions after my German ex girlfriends in strict alphabetical order: Angelika, Birthe, Christine…

  6. Oddball

    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

    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

    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. “Old school” !!!

  10. Rodion

    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.

    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

    Oh no! Don’t touch current version numbering.
    Old school is best for openSUSE.

  13. petyanamlt

    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

    7.

  15. hron84

    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

    Old school only

  17. Golos

    “Ubuntu style”: YY.MM Is Nice!!! :-) OpenSUSE 11.11 ;-)

  18. Sultan

    “Old school /Mandriva variation”: YY.counter (2 digit year, counter starts at zero)

  19. ferhiord

    “Old school” or “Old school/Mandriva variation”

  20. vespas

    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. 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. OpenSuSE 2.6.37.3
    OpenSuSE 2.6.38
    OpenSuSE 2.6.38.5
    OpenSuSE 2.6.38.7

    Well, you understand?

    • jrdls

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

      • Kalle Anka

        So what if openSUSE goes the way of Debian and includes other kernels such as kFreeBSD and eventually the Hurd?

  23. OpenSuSE 12
    OpenSuSE 12. define #1
    OpenSuSE 12. declare №2
    OpenSuSE 12. call 3

  24. Ansus

    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

    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

    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

    Old school.

  28. Maxim

    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

      @macias

      Best suggestion so far. Old school with purpose.

    • JirkaZ

      Old school with a purpose. This is the best idea for me, too.

    • jik

      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

    Old school, but should be strictly defined the number of minor builds, imo.

  30. macias

    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

    Just keep it “old school”. As Dean already pointed out, there is no problem.

  32. 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

    YYYY.2-bit

    2012.00
    2012.01 (may be used)
    2012.10 (likely not used)
    2012.11 (likely not used)
    2013.00

  34. a23d56

    0.000 thru 9.999

    each release +0.001

    Next release starts at 0.000 to start the new scheme.

  35. kzarog

    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

    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

    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

      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

    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

    Hex or binary. Gotta be the way to go :)

  40. Martin

    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

    4. Old school/Mandriva i.e. 11.5 next. Ideal time to change to make the major number represent the year.

  42. 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. 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

    “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

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

    YYYY.MM

  46. some_hockey_nut

    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

    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

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

    Next release…. 100100100101.100.FFFF

  49. vladano

    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. Seasons for me.

  51. jik

    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

    I think I would like to change the way my birthdays go…. next birthday I am 2011.46

  53. 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

    Old school, don’t change it.

  55. Richard

    Old school served us well for over a very long time already, what is it 15 years or more!

  56. I prefer the Ubuntu style, simple and very clear!

  57. marvin

    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

    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.