Re: [gentoo-dev] rfc: revisiting our stabilization policy

[Tom Wijsman]

On Wed, 15 Jan 2014 23:28:04 -0800
Christopher Head <chead@×××××.ca> wrote:

> If I need or want a feature or bugfix which isn’t in the newer
> version, I always have the choice to use ~.

Yes.

> If I don’t, why do I care if the package is a year old? I lose none
> of my time to use the old version, since it does all I want;

This is under the assumption that the old version has no further
implications, which is a false assumption; because the older a stable
ebuild get, the higher the chance is that it becomes incompatible with
its libraries and/or causes blockers. Even further, a security bug for
an old version of a library it depends on could cause its removal.

Regardless, it'll work fine for some time; and you can even pull it
further by attempting to keep things around and not upgrade, but at a
certain point it'll come costly to hold on to. I'm not saying it is a
lot of your time, but it's a bit more than none of your time.

This point becomes much more clear if you imagine using software from in
the early Linux years, most of them would be incompatible with today.

> I lose a
> nonzero amount of time if I get a version which breaks things (even
> if the only time I lose is the time it takes to downgrade),

Depends on whether the stable version is as perfect as one thinks it
is; an upgrade can go two ways, it improves or regresses. (Well, three
ways as it can stay the same, but that wouldn't demonstrate the point)

> so it’s in my best interest to use the stable versions of such
> packages, even if they’re a month, a year, or three years old.

Based on what you know, what you need and that you can resist change;
yes, but this doesn't take into account what you don't know, you don't
know you need and the improvements that change can bring.

While it doesn't happen often, some people will say "if I knew this
earlier, I would have already upgraded a long while ago"; either
because the new version brings something good, or the old version has a
regression they were not aware of yet or came due to incompatibility...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D