Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming

Romance and Rebellion In Software Versioning 86

Posted by timothy from the one-point-2-slash-b-codename-priapic-porcupine dept.
joabj writes: Most software releases more or less follow the routine convention of Major.Minor.Bugfix numbering (i.e. Linux 4.2.1). This gives administrators an idea of what updates are major ones and might bring compatibility issues. As Dominic Tarr points out in his essay "Sentimental Versioning," a few projects boldly take on more whimsical schemes for versioning, such as Donald Knuth's use of successive Pi digits to enumerate new updates to TeX, or Node.js's punk-rock careening between major and minor releases. If you break convention, Tarr seems to be arguing, at least do so with panache.
This discussion has been archived. No new comments can be posted.

Romance and Rebellion In Software Versioning More

Romance and Rebellion In Software Versioning

Comments Filter:

  • Semantic Versioning (Score:5, Informative)

    by bondsbw ( 888959 ) on Monday September 28, 2015 @11:10AM (#50613053)

    http://semver.org/ [semver.org]

  • Sofware versions should stop at 10 . . . (Score:5, Funny)

    by PolygamousRanchKid ( 1290638 ) on Monday September 28, 2015 @11:13AM (#50613075)

    Some can go up to eleven, but most should stop at 10.

    • Re: (Score:2)

      by Kenshin ( 43036 )

      But the minor number should keep going past 10, just to make things difficult for pedants. :)

      "OS X 10.11? Where's OS XI? Oh my god I'm going insane!"

  • Sure... (Score:1)

    by Anonymous Coward

    you could do something whimsical. Alternately, you could not be an asshat. Sematic versioning FTW!

  • Use Gödel numbering (Score:5, Funny)

    by vikingpower ( 768921 ) on Monday September 28, 2015 @11:28AM (#50613163) Homepage Journal
    Use one series of primes for major.
    Use a second series of primes for minor.
    Use a third series of primes for patches/micro/bug fixing.

    The three sets of primes should be disjoint.

    For each release, multiply major with minor with micro. That is your unique version number.

    You may add some sugar by adding powers of these primes for various locales, database compatibility etc. etc.

    • Re: (Score:2)

      by Rob Riggs ( 6418 )

      I like it.

      P.S. My UID is also semiprime.

      • Re: (Score:1)

        by Anonymous Coward
        And your post number (#50614169) is a triprime.

        50614169 = 113 x 307 x 1459
  • It seems many developers stopped caring about versioning several years ago. I've been torn on whether it was just marketing finally overtaking common sense or too many inexperienced but successful developers showing up and making some poor choices.

    • People don't consider a lot when they do things. There's an old convention of 0.x being "incomplete", such that we have some rather mature products in pre-1.0 stable releases without all of the features and finalized interfaces which constitute a completed product. There's a newer convention of Major.Minor.Revision, based on the old Major.Minor.Revision, by which "revision" means "nothing new, fixed some defect", while "Minor" means "Something new, works exactly as before if you're not using the old thin

      • Then you have Ubuntu and Debian, who follow a very clear policy: Each release will receive no updates which change any functionality.

        Well that's the ideal, whether reality lives up to it is another matter.

        • The major deviants are mostly Firefox and Chrome, since sometimes you need to pull Firefox up a few versions to get a security fix; they often backport the fixes.

      • Then you have Ubuntu and Debian, who follow a very clear policy: Each release will receive no updates which change any functionality. If it worked on release day, it will work in exactly the same way at EOL. Bugfixes may enable previously-broken functionality; they try not to alter functionality such that previous work-arounds start behaving differently, unless the application is so crippled as to be unuseful. This is okay because the scope of a distribution release implies a major change; Ubuntu has a point release system for LTS to signify minor feature updates.

        Actually, Ubuntu just bumped python3 from 3.4.0 to 3.4.3 in Trusty LTS yesterday.

        • 3.4.3 looks like a pure bugfix and improvement release, not a major feature release. They did change some casing in the http.cookies module, which is concerning.

      • RedHat takes a different, more Apple-like approach: Their point-releases are just inline updates, like Ubuntu LTS; but they're *major* updates, removing old features and subsystems, integrating completely new systems, changing behaviors, and generally breaking all kinds of shit. There's no support for the previous point release, at all; if you call RHEL support, they tell you to update or else they have nothing for you. The difference between RHEL 6.10 and RHEL 7 is functionally similar to the difference between RHEL 6.9 and RHEL 6.10, or RHEL 7 and RHEL 7.1.

        Here you're actually not completely correct. Red Hat does provide Extended Update Support (EUS) as an option to customers that want to standardize on a minor RHEL release for some time, usually two years.

  • It seems that many projects now opt for a regular progression of numbers with or without any major new features. Even Ubuntu releases, formerly the occasion for the introduction of some initially broken new feature, have become boring affairs. Even the well-numbered Linux kernel appears to break the major.minor paradigm. Besides the addition of more and more drivers, was there anything particularly disruptive in the move from Linux 3.19 to Linux 4.0? Beyond the third digit of the bug fix releases, Linux ver

    • OpenBSD dees time-based versioning. Every six months, the version number increments by 0.1 - there's a new release every May 1st and Nov 1st. The change in major version number means nothing other than it's gone from x.9 to (x+1).0

      Simple.

  • Key rules. (Score:5, Interesting)

    by jellomizer ( 103300 ) on Monday September 28, 2015 @11:33AM (#50613201)

    1. Stay Consistent!!! Don't drop your versioning and swap to another one. Like Microsoft, Firefox, to a lesser extent Apple.
    2. If you are using names make sure you know which one is greater. Ubuntu method of going up alphabetically is a good example.
    3. Insure development milestones are consistent with the version bumps. So Version 2 to version 3, should be just as large as from version 3 to 4.

    The key importance to versioning is so we know what is the newest/newer version and if you have a major version you will expect some compatiblity changes.

    • Re: (Score:1)

      by Anonymous Coward

      I've grown accustomed to a variation on Microsoft's four-point versioning system. It's officially Major.Minor.Build.Revision, but I've found reversing the meaning of the last two sections to be more helpful. Major.Minor.Revision.Build just works better for me.

      Major versions are breaking revisions. The file format is incompatible. The database architecture changed. The network protocol is completely different. That sort of thing. You increment this when you have a major architecture overhaul or when you make

    • Re: (Score:1)

      by sarguin ( 702714 )

      2. If you are using names make sure you know which one is greater. Ubuntu method of going up alphabetically is a good example.

      Names like One, Two, Three, Four, Five, ... sounds good to me ;)

    • Re: (Score:2)

      by glwtta ( 532858 )
      2. If you are using names make sure you know which one is greater. Ubuntu method of going up alphabetically is a good example.

      I use Medoc Grads Crus in increasing order of subjective quality - pretty much as obvious as it gets.

  • KISS (Score:4, Informative)

    by Moof123 ( 1292134 ) on Monday September 28, 2015 @11:43AM (#50613263)

    Please keep this crap simple. It is maddening for secondary tools (ones I don't use daily) to get all cutesy with the Silky Lizard release, which is also known at the 2015 release, but has an about me of 3.2.0.1 hotfix 430. Searching under all three is necessary since everyone adopts a different preferred method to refer to the dang thing.

    On the whole I greatly prefer versions that are year.month based so it is very easy to recognize how long in the tooth something is. XYZ 2015.01 tells me it is the January 2015 release.

    • Re: (Score:3)

      by Junta ( 36770 )

      On the whole I greatly prefer versions that are year.month based so it is very easy to recognize how long in the tooth something is

      Of course there are situations where that really does not matter and fretting about how old a piece of code is pointless worrying. For example, the code to decrypt a DVD hasn't change in an eternity, but there's no good reason to expect a change to be needed on that front. A library dedicated to that purpose might not change because there's no point, not because it's abandoned.

    • The big drawback of year.month over major.minor is that year.month gives no indication of the magnitude of changes. Can I install 2015.09 and be certain all of the features I use daily are still there? What's the difference in file format between 2014.06 and this new version?
      Now I realize major.minor is not an ironclad guarantee either, but it gets me closer than year.month.

  • Microsoft Windows 42

  • With year-based, I know how old the software is and I know which version is newer. Maybe add something extra to indicate if it's a major change, or if it gets long term support.

  • If your new version has limited new visible functionality let users vote on a name of the most current release. Can you name the new feartures of android Marshmellow? If nom, you do know the name!

  • We run with a full continuous integration cycle... with continuous release. Our software version is whatever the Git hash is. This is for a large computational science library that's in use by hundreds of researchers around the globe.

    You can read about some of our software development methodology here:

    http://openresearchsoftware.me... [metajnl.com]

    Although, that's a bit dated now and a newer article has already been accepted by the Journal Of Open Research Software and should be out "real soon now". You can see an ear

    • Re: (Score:3)

      by fisted ( 2295862 )

      with continuous release.

      Ain't no rockstar brogrammer got time for releng, right?

      Our software version is whatever the Git hash is.

      You're saying this as if that was something to be proud of, rather than a demonstration of laziness...

      This is for a large computational science library that's in use by hundreds of researchers around the globe.

      Thanks for the warning.

      • Quick to criticize and call names I see.

        You obviously didn't even bother a cursory glance at the two papers I pointed to. We spend a LOT of time doing release engineering... we just build it all into an automated system so that we can do multiple "releases" per day.

        We actually test every code change against a large set of our downstream users codes... automatically. Yes, every change... and yes, against _user's_ applications that are built using our library (even users located on the other side of the wor

    • Re: (Score:1)

      by Anonymous Coward

      That sounds like the worst versioning scheme I've ever heard of, and requires gobs of research just to determine the order of versions. I assume that it includes the presumption that the tip of the repository is always bug free. Assuming that you have different development branches and a strict testing policy before copying a branch up to mainline, this could be feasible. But in this case, you'd expect that you could have your CI tool also include a strictly monotonically increasing integer to help your use

      • Look at my reply to the guy above you for a little more detail.

        We _do_ actually test every every code change _before_ it enters a "devel" branch (everything flows through tested pull requests). Part of that testing is actually testing against _downstream_ applications (user's applications). Once it's deemed fit to go into "devel" the PR is merged and a new set of automated testing is kicked off... with more extensive testing against all downstream applications. If that passes then a "release" is automati

  • Do it with Panache? (Score:3)

    by FatdogHaiku ( 978357 ) on Monday September 28, 2015 @01:24PM (#50614067)
    OK, but I'm still on Panache 0.92.4!
    Do I need to update to 1.1.x?
    Also, it would seem that certain young women on the internet have Panache x.x.x.

  • Just like kids and puppies, it's cute when they are small, then develops into an annoyance you put up with for decades.

    It's also painfully annoying when you have a version of something (e.g. 7.0), then another version contained in the driver file (340.xx), and still another version reported in a OS-unique manner (e.g. A.B.C.D on Windows). Yes, I'm looking at you, nVidia.

    Similar case for themed server names versus role-based, owner-based, rack-location-based, physical-location-based -- anything that allows a

  • I count four, no, five version numbering schemes:
    - romantic
    - rebellious
    - traditional (major.minor.bugfix)
    - marketing (year.month)
    - irrational (a.k.a. Mine's Bigger: Firefox, Chrome)

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close