4 ms·

Not convinced by rolling releases

49 points by pavs 14y ago

ChuckMcM 14y ago
Nice piece by Mark. As someone who is used to "version" I too am somewhat off put by the rolling release concept. My challenge is how to say what is true, for example this javascript will run in Chrome for all Chrome > build xyz? It was simpler (not saying better, just simpler) to V2.5 or later supports this.
- networked 14y ago
  >for example this javascript will run in Chrome for all Chrome > build xyz? It was simpler (not saying better, just simpler) to V2.5 or later supports this On a related note, a few years ago I went from assigning version numbers to the releases of some of my projects to simple date-based versions (e.g., "version 20130307"). One of the reasons I switched to using dates is that beyond v1.0 it's often hard to assign versions to software in a meaningful fashion (is our next release a "v3.0" or a "v2.1"?); that is especially true if your software isn't of the commercial variety where a major version increase hinges on the question of "is this substantially different to charge an upgrade fee of $N for?". One exception to this naming rule is that I assign low numerical versions (e.g., "v0.03") to early code to indicate its quality. What would you say about this practice vs. build numbers or traditional version numbers? Edit: To clarify, I don't think this alone constitutes going rolling release. Overall, I found it pleasant to not have to think about version numbering. Release dates also seem to be easier to remember and interpret than mere build numbers (a half-forgotten date like "201207..." is easier to pin down than "build 12573... something")
  - qznc 14y ago
    Use http://semver.org/ http://semver.org/ it provide clear semantics on how to increase version numbers.
  - ChuckMcM 14y ago
    Well, I've grown up with semantic version numbers. In those there was a document somewhere that described exactly what the version numbers "meant" in terms of compatibility. So Major.minor,sub-minor was the most common, the policy there was : * major number change, may have incompatible changes with APIs. Applications depending on a major number won't be compatible with the previous version of the library. * minor number change, changes by 'addition' only, no changes to existing code necessary, backward compatibility testing advised. * sub-minor number change. No semantic changes, bugs and other defects fixed, some workarounds may no longer be needed. With rolling releases it seems the only safe thing you can assume is that no earlier release is compatible and later releases are probably compatible. That seems like a step backward.
ineedtosleep 14y ago
Most of it made sense until: But if we want to get beyond being a platform for hobbyists, we need to accelerate the work on Unity to keep up with Android, Chrome, Windows and Apple. And that’s more important than taking care of the needs of those who don’t share our goal of a free software norm. Who is he talking about there? Aren't many of the complaints coming from people who are thinking that Ubuntu's heading towards a less free(dom) direction?
- zalew 14y ago
  Probably about those dissatisfied that Canonical develops its own DE (and now its own X replacement) instead of developing on top of what's out there and with the rest of the community. They just don't wait for the rest and do what they feel is appropriate for the popularity of Ubuntu (and therefore Linux). If one likes it or not basically depends on one's political stance on this issue.
  - mich41 14y ago
    > They just don't wait for the rest and do what they feel is appropriate for the popularity of Ubuntu (and therefore Linux) The word "Linux" doesn't even appear anywhere on their home page [1] or "About Ubuntu" page [2]. "GNU" probably never did and "free" appears only in the "cheaper than Windows" context. Nowadays Canonical basically takes a bunch of community and FSF projects, patches them internally to their liking and ships with custom frontend without giving much credit to the original authors. "Developed by the amazing Ubuntu community of open source experts". They are as much about promotion of Linux and FOSS as Apple is about promotion of BSD Unix. Please stop spreading disinformation. [1] http://www.ubuntu.com/ http://www.ubuntu.com/ [2] http://www.ubuntu.com/ubuntu http://www.ubuntu.com/ubuntu
    - zalew 14y ago
      > They are as much about promotion of Linux and FOSS as Apple is about promotion of BSD Unix. strawman. I said popularity, not promotion. > Canonical basically takes a bunch of community and FSF projects, patches them internally to their liking and ships with custom just like most devs take a bunch of opensource projects, customize them, and ship them to their customers, only for money? that's the nature of the license - other people can use it these ways. it's annoying when bypassers are more concerned and noisy about this than said parties. > Please stop spreading disinformation. as I said, it's political. let's agree to disagree. sent from my debian.
_mpf 14y ago
"Comments are closed."
- wcchandler 14y ago
  The mailing list thread is better suited for discussion. https://lists.ubuntu.com/archives/ubuntu-devel/2013-February/036537.html https://lists.ubuntu.com/archives/ubuntu-devel/2013-February...
- jff 14y ago
  Ubuntu in a nutshell.
CoffeeDregs 14y ago
There's a middle ground that's kind of lost in this argument: create a 'rolling' distribution and cut-and-stabilize LTS releases from it. This is kind of how I treat 'testing' in Debian and I've only seen a problem once in 5 years. If you want stability and consistency, use an LTS release. If you want more recent software, use the 'rolling' release. While this is mentioned in TFA ("edge"), it's glossed over.
- fuzzix 14y ago
  Just to echo this, I do much the same with Slackware. I use -current on some machines. Every time a release is pending, work on -current slows down (or does it ramp up?) and it is stablised. It's essentially a development release rather than being explicitly labelled "rolling" (and, in fact, its use as a day-to-day distribution is generally considered A Bad Thing if you're not a Slackware developer/tester). It just happens to have the bonus of also being a pretty bleeding-edge, yet stable rolling release. So, it's possible to achieve both a rolling release and "stable", versioned releases.
  - mhurron 14y ago
    Slackware-current is basically as stable as Fedora is at any given time so it's hard to really discourage its use. Honestly, Slackware is almost a RHEL/Fedora type ecosystem when just taking about official packages. Slackware-current gets new stuff, Slackware releases only get bug fixes, and not too many of them at that.
    - jackalope 14y ago
      I'm not sure I agree with that comparison. Slackware-current will become the next stable release once all of the kinks have been worked out. Is RHEL ever really a snapshot of Fedora?
      - mhurron 14y ago
        > Is RHEL ever really a snapshot of Fedora? Basically yes, Fedora is Red Hat getting free testing of features and when it's time to create a new RHEL release, they grab a Fedora release, set it in stone and work from that. http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux Red Hat Linux 6.2 → Red Hat Linux 6.2E Red Hat Linux 7.2 → Red Hat Enterprise Linux 2.1 Red Hat Linux 10 beta 1 → Red Hat Enterprise Linux 3 Fedora Core 3 → Red Hat Enterprise Linux 4 Fedora Core 6 → Red Hat Enterprise Linux 5 Fedora 12, 13 → Red Hat Enterprise Linux 6
jmathai 14y ago
>> If you’ve done what you want for Ubuntu, then move on. That’s normal – there’s no need to poison the well behind you just because you want to try something else. If only we could apply that to everything we use.

49 points by pavs 14y ago

Nice piece by Mark. As someone who is used to "version" I too am somewhat off put by the rolling release concept. My challenge is how to say what is true, for example this javascript will run in Chrome for all Chrome > build xyz? It was simpler (not saying better, just simpler) to V2.5 or later supports this.

networked 14y ago
>for example this javascript will run in Chrome for all Chrome > build xyz? It was simpler (not saying better, just simpler) to V2.5 or later supports this On a related note, a few years ago I went from assigning version numbers to the releases of some of my projects to simple date-based versions (e.g., "version 20130307"). One of the reasons I switched to using dates is that beyond v1.0 it's often hard to assign versions to software in a meaningful fashion (is our next release a "v3.0" or a "v2.1"?); that is especially true if your software isn't of the commercial variety where a major version increase hinges on the question of "is this substantially different to charge an upgrade fee of $N for?". One exception to this naming rule is that I assign low numerical versions (e.g., "v0.03") to early code to indicate its quality. What would you say about this practice vs. build numbers or traditional version numbers? Edit: To clarify, I don't think this alone constitutes going rolling release. Overall, I found it pleasant to not have to think about version numbering. Release dates also seem to be easier to remember and interpret than mere build numbers (a half-forgotten date like "201207..." is easier to pin down than "build 12573... something")
- qznc 14y ago
  Use http://semver.org/ http://semver.org/ it provide clear semantics on how to increase version numbers.
- ChuckMcM 14y ago
  Well, I've grown up with semantic version numbers. In those there was a document somewhere that described exactly what the version numbers "meant" in terms of compatibility. So Major.minor,sub-minor was the most common, the policy there was : * major number change, may have incompatible changes with APIs. Applications depending on a major number won't be compatible with the previous version of the library. * minor number change, changes by 'addition' only, no changes to existing code necessary, backward compatibility testing advised. * sub-minor number change. No semantic changes, bugs and other defects fixed, some workarounds may no longer be needed. With rolling releases it seems the only safe thing you can assume is that no earlier release is compatible and later releases are probably compatible. That seems like a step backward.

ineedtosleep 14y ago

Most of it made sense until: But if we want to get beyond being a platform for hobbyists, we need to accelerate the work on Unity to keep up with Android, Chrome, Windows and Apple. And that’s more important than taking care of the needs of those who don’t share our goal of a free software norm. Who is he talking about there? Aren't many of the complaints coming from people who are thinking that Ubuntu's heading towards a less free(dom) direction?

zalew 14y ago
Probably about those dissatisfied that Canonical develops its own DE (and now its own X replacement) instead of developing on top of what's out there and with the rest of the community. They just don't wait for the rest and do what they feel is appropriate for the popularity of Ubuntu (and therefore Linux). If one likes it or not basically depends on one's political stance on this issue.
- mich41 14y ago
  > They just don't wait for the rest and do what they feel is appropriate for the popularity of Ubuntu (and therefore Linux) The word "Linux" doesn't even appear anywhere on their home page [1] or "About Ubuntu" page [2]. "GNU" probably never did and "free" appears only in the "cheaper than Windows" context. Nowadays Canonical basically takes a bunch of community and FSF projects, patches them internally to their liking and ships with custom frontend without giving much credit to the original authors. "Developed by the amazing Ubuntu community of open source experts". They are as much about promotion of Linux and FOSS as Apple is about promotion of BSD Unix. Please stop spreading disinformation. [1] http://www.ubuntu.com/ http://www.ubuntu.com/ [2] http://www.ubuntu.com/ubuntu http://www.ubuntu.com/ubuntu
  - zalew 14y ago
    > They are as much about promotion of Linux and FOSS as Apple is about promotion of BSD Unix. strawman. I said popularity, not promotion. > Canonical basically takes a bunch of community and FSF projects, patches them internally to their liking and ships with custom just like most devs take a bunch of opensource projects, customize them, and ship them to their customers, only for money? that's the nature of the license - other people can use it these ways. it's annoying when bypassers are more concerned and noisy about this than said parties. > Please stop spreading disinformation. as I said, it's political. let's agree to disagree. sent from my debian.

_mpf 14y ago

"Comments are closed."

wcchandler 14y ago
The mailing list thread is better suited for discussion. https://lists.ubuntu.com/archives/ubuntu-devel/2013-February/036537.html https://lists.ubuntu.com/archives/ubuntu-devel/2013-February...
jff 14y ago
Ubuntu in a nutshell.

CoffeeDregs 14y ago

There's a middle ground that's kind of lost in this argument: create a 'rolling' distribution and cut-and-stabilize LTS releases from it. This is kind of how I treat 'testing' in Debian and I've only seen a problem once in 5 years. If you want stability and consistency, use an LTS release. If you want more recent software, use the 'rolling' release. While this is mentioned in TFA ("edge"), it's glossed over.

fuzzix 14y ago
Just to echo this, I do much the same with Slackware. I use -current on some machines. Every time a release is pending, work on -current slows down (or does it ramp up?) and it is stablised. It's essentially a development release rather than being explicitly labelled "rolling" (and, in fact, its use as a day-to-day distribution is generally considered A Bad Thing if you're not a Slackware developer/tester). It just happens to have the bonus of also being a pretty bleeding-edge, yet stable rolling release. So, it's possible to achieve both a rolling release and "stable", versioned releases.
- mhurron 14y ago
  Slackware-current is basically as stable as Fedora is at any given time so it's hard to really discourage its use. Honestly, Slackware is almost a RHEL/Fedora type ecosystem when just taking about official packages. Slackware-current gets new stuff, Slackware releases only get bug fixes, and not too many of them at that.
  - jackalope 14y ago
    I'm not sure I agree with that comparison. Slackware-current will become the next stable release once all of the kinks have been worked out. Is RHEL ever really a snapshot of Fedora?
    - mhurron 14y ago
      > Is RHEL ever really a snapshot of Fedora? Basically yes, Fedora is Red Hat getting free testing of features and when it's time to create a new RHEL release, they grab a Fedora release, set it in stone and work from that. http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux Red Hat Linux 6.2 → Red Hat Linux 6.2E Red Hat Linux 7.2 → Red Hat Enterprise Linux 2.1 Red Hat Linux 10 beta 1 → Red Hat Enterprise Linux 3 Fedora Core 3 → Red Hat Enterprise Linux 4 Fedora Core 6 → Red Hat Enterprise Linux 5 Fedora 12, 13 → Red Hat Enterprise Linux 6

jmathai 14y ago

>> If you’ve done what you want for Ubuntu, then move on. That’s normal – there’s no need to poison the well behind you just because you want to try something else. If only we could apply that to everything we use.