

Not convinced by rolling releases - pavs
http://www.markshuttleworth.com/archives/1228

======
CoffeeDregs
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
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
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
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
> 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>

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

~~~
jackalope
From the same article:

 _RHEL trees are forked off the Fedora repository, and released after a
substantial stabilization and quality assurance effort._

Which adds a quote from the Fedora Project:

 _Red Hat Enterprise Linux is a commercial enterprise operating system and has
its own set of test phases including alpha and beta releases which are
separate and distinct from Fedora development._

And on _that_ page[1] it states that RHEL6 is based on a _"Mix of Fedora 12
Fedora 13 and several modifications"_.

Sorry to be pedantic, but that's significantly different than the Slackware
model. Maybe it's just PTSD; I fled from RH in the old days onto the path that
led to Slackware, so any comparison makes me touchy.

[1]
[https://fedoraproject.org/wiki/Red_Hat_Enterprise_Linux?rd=R...](https://fedoraproject.org/wiki/Red_Hat_Enterprise_Linux?rd=RHEL#History)

------
ineedtosleep
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?

~~~
wmf
I think he's talking about the "I have Ubuntu set up in some obscure
configuration exactly the way I like it, now please never break anything"
people. The "leet" users. For every leet hacker he sacrifices, Shuttleworth is
expecting to gain 10 normal users.

~~~
gph
Heh, I fall somewhere into that group in that I think Unity is terrible. That
said, I do basically agree with most everything that he says in the article.
No one is ever going to get exactly what they want in a project as large as
Ubuntu. That's why there's Mint :D

Time will tell whether the Unity gamble was worth it. Personally I don't think
they will be able to keep up with Apple/Android/Microsoft in Mobile, but I
thought those companies were leaving a bit of a void in the PC power user
field that Ubuntu could have run wild in. We'll see if he's right, but I think
ubuntu will only ever grab the 'hobbyists' in the mobile market, his dreams of
major market-share across PC/mobile/tablet are pipe-dreams IMO. And for each
person like me that moves on, I just don't see there being 10 others that will
now fill in behind me.

------
ChuckMcM
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
>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
Use <http://semver.org/> it provide clear semantics on how to increase version
numbers.

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

------
_mpf
"Comments are closed."

~~~
wcchandler
The mailing list thread is better suited for discussion.

[https://lists.ubuntu.com/archives/ubuntu-
devel/2013-February...](https://lists.ubuntu.com/archives/ubuntu-
devel/2013-February/036537.html)

