On Wed, 15 Jan 2014 23:28:04 -0800 Christopher Head <ch...@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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
