
Stop supporting old releases - okket
https://medium.com/@mikeal/stop-supporting-old-releases-70cfa0e04b0c
======
tscs37
> They keep old releases in their CI configuration and block PR’s from being
> merged if they don’t work on older release lines.

If you are doing that, shame on you, that's not how stable and long-term-
support works at all. If you backport, you backport on a best-effort basis,
not on a must-have basis.

There is 0 sense in supporting old versions when you just backport all the new
stuff into them anyway.

>You, in your GitHub project, probably don’t have the time or resources to
manage more than one release line of development.

That is certainly true. Over the whole essay I don't find much reason _not_ to
have a LTS schedule.

I don't _have_ to backport all the stuff to older releases. My own policy is
that any previous release will receive security patches as long as I can be
made to care (usually about 1 year and in one case I support a 3 year old
release of a project with security patches)

It is not _that_ much effort to patch security stuff. It doesn't take you away
from your project for days, it costs you a few hours and some users of your
project will be happier for it. That's all I want.

~~~
ProblemFactory
> I don't have to backport all the stuff to older releases. My own policy is
> that any previous release will receive security patches

Besides it being easier, isn't _not_ porting feature patches the entire point
of Long Term Support releases? People use LTS because they don't want any
unexpected behaviour changes, only security updates.

~~~
tscs37
Yeah it's basically the only way you should be doing LTS.

------
3pt14159
I generally tow the line when it comes to software, but I do have a couple
contrarian opinions and one of them is that LTS is really, really dumb. Not
just for maintainers, for everyone.

LTS destroys your codebase. LTS allows mistakes like pushing state into your
server that you didn't know was there. LTS makes it _much_ harder to upgrade
because by the time you're moving off of, say, Ubuntu 12.04 the whole world
has changed. LTS multiplies the number of things that can go wrong. LTS makes
people think that the OS is going to be around forever so they don't architect
their devices to be OS-updateable. IoT is bad now, but it's slowly getting
worse too because half these devices are stuck on some out of date version of
linux running some out of date version of Python.

All my servers run Ubuntu 17.10. Rails is on the latest version. Ruby is on
the latest version. I don't pin any of my gems and every time I upgrade Ruby I
upgrade the latest version of all the gems too.

This is only possible with extensive testing, and mistakes do get made here
and there, but overall it's much, much easier handling these issues one at a
time. The only thing I don't do is keep current on packages that I install via
`apt` because I don't want to risk building from source.

~~~
blueflow
Using Ubuntu has the big advantage that you dont have to maintain the packages
yourself, so you just dont notice all the regressions that maintainer have to
deal with on a daily basis.

Seeing fundamental things like glibc or gcc breaking almost every release
makes you start to value LTS releases a bit more.

Disclaimer: Im maintainer myself and i feel your opinion is disrespectful
towards the people who fix regressions for you (for free, even!).

~~~
3pt14159
There is no disrespect. I don't disrespect hardworking people trying to make
the world better. This is just what I've found after writing software for
decades. It's a viewpoint that I'm willing to change, but also one I think
others should entertain so that all our software gets better and stays
current.

Also, as I said in the original comment, I only lean on apt for a minority of
things. Most stuff gets upgraded right away and you know what? I find and fix
or communicate bugs because I'm on the bleeding edge. And I frankly do not see
how my using apt invalidates my views on LTS. In the ruby world upgrading is
almost never a pain because most of us keep current and test our codebases. I
shouldn't be maintaining packages myself, and I do think that if the people
behind Debian / Ubuntu / rando packages available took my worldview it would
be easier to always be on the latest version and upgrading shit wouldn't be
this giant headache all the time.

Common, glibc should break or break something every release. This is insanity.

~~~
derefr
In language package ecosystems (like Ruby's), _you_ decide when to push out a
new release. You find that updating your lockfile breaks your code, so you put
it off. You push out a few versions without updating the deps. Then, in one
release, you update them all, fix all the problems that introduces, and then
push out a new version that has the new deps and works with them.

OS package management doesn't work this way, because, for the most part, for
almost the entire history of OSes, developers have had no control over the
environment their application is running under. In a lot of cases (enterprise
IT; academic/HPC mainframes; PaaSes) someone else has an upgrade schedule for
the OS packages, and you don't get any say on when it happens. The OS updates,
your package breaks, your problem. You can _maybe_ ask the ops department to
hold off on updating, or have your PaaS "pin" your stack (until it becomes
deprecated.) Either way, you're now vulnerable to security vulnerabilities
while (hurriedly) working to push out the new release so that ops can get back
to doing its job as normal.

LTS is a guarantee by the OS distributor that your ops staff _can_ update any
package at any time (from the LTS repos, at least), and such updates _won 't_
break your deployed custom software. So LTS solves the cases above:
enterprise/academic/HPC/PaaS ops staff can just upgrade as they will, without
worry that anyone will tell them to hold off.

But the value of LTS goes even further: if updates are guaranteed by the
distributor to not break your runtime environment, then you can actually
_allow OS package upgrades to happen completely automatically and
asynchronously_ to your development release schedule. The OS can just update
_itself_. The OS distributor is now, themselves, part of your ops staff,
ensuring that these updates aren't bothering anyone downstream of them. Your
actual company doesn't have to care about the OS. It's _always_ going to be
secure, because it's going to update as soon as vulnerabilities are
discovered+patched, and you can just deploy your code at your own pace without
worry.

Now, mind you, this all might sound quaint to people who bake containers for
everything and treat said containers' host OS as immutable infrastructure. For
these people, OS package security vulnerabilities aren't really something you
can let "fix itself"; they're something that requires baking a new version of
your container-image, just as app library-dependency security vulnerabilities
would be. Relying on OS services rather than bundling a copy into your
container-image is a trade-off in this case: you don't get to pin the version
of a dependency to ensure its _exact_ behaviour, but in exchange, the distro
will attempt to ensure that it will be free of security vulnerabilities while
being _pretty much_ the same version you started with.

(Oh, and as a side-benefit, usually LTS package updates don't force system
reboots. Recently even kernel updates don't, with fancy ksplice-based patch
distribution channels. So LTS releases _also_ mean long individual-host
uptimes, which is handy if you're running a service on the cheap and can't
afford much horizontal scaling to manage load-balancing under rolling updates,
but want five or more 9s of availability anyway. Try getting _that_ using
immutable-infrastructure reboot-to-update VM images.)

------
antirez
Well said. Redis is almost 100 percent backward compatible back to the first
release, so I never found a good reason to support old released. Want support?
Upgrade... Of course this does not stop an infinite stream of bug reports
about several years old releases.

~~~
jt2190
I believe that the Angular team is also taking this approach. [1]

[1] At ng-conf 2017, the core team was asked whether they'd consider
designating LTS releases, and the answer was essentially what you're saying
here: They work very hard to be backward compatible, and encourage everyone to
move _forward_ instead of getting stuck in the past.

~~~
gaius
Didn't they break everything between versions 1 and 2? If that's "backwards
compatible" I hate to think what their LTS would have looked like.

~~~
dcherman
They did, but quite honestly they should have just renamed the framework;
Angular 1->2 is less of an upgrade and more of a completely new framework that
happens to share the same name. It was a mistake imo, but one they made
because Angular is a household name amongst web devs.

From what I understand, they've done a better job from Angular 2-5.

------
taeric
The destructive practice is not knowing how to write stable things. There is a
small period at the beginning of a project where stability doesn't matter.
There is a long period where instability will lead folks away.

~~~
mschuster91
> The destructive practice is not knowing how to write stable things.

Well, you can do it the Linux way, too: even if it is a bug, as long as fixing
it breaks existing userland code, the fix gets reverted and the docs adjusted.

Compare this to anything except plain JS, jQuery and PHP - breakages all the
time, everywhere, because no one values backward compatibility any more
(python2=>3, for one, or whatever MS is choosing as the current framework to
develop Windows applications now). This is the difference that MS took with
the win32 layer and what made them successful - until they started ignoring BC
in favor of loading new crap on consumers and enterprises alike every
patchday.

~~~
majewsky
I think it's dishonest to claim that Python does not value backwards
compatibility because of the Python 2->3 update. That's a _single_ point of
backwards-incompatibility in a project that has been going on for decades. (If
you don't agree, please list all the backwards-incompatible changes that have
been introduced in the years upon years since Python 3.0.)

------
wongarsu
>They keep old releases in their CI configuration and block PR’s from being
merged if they don’t work on older release lines.

Wait, people do that? If every PR lands on the next release _and_ on the LTS
release, how is the LTS branch different from the latest release? Isn't the
point of LTS that it stays the same (except bugs) and isn't evolving?

I must be missing something obvious here.

~~~
chrisseaton
I think they're talking about code bases that use the software with the LTS,
not the code base of the software with LTS itself. They test against latest
and LTS, and your PR needs to work on both.

------
alangpierce
I think there's some ambiguity here around LTS for the project itself vs its
dependencies, but as one concrete example, I support node 4 for an open source
project I maintain, and I would defend that decision.

In my case, the only additional effort needed for node 4 is to use
Array.prototype.indexOf instead of Array.prototype.includes, which is mildly
annoying, and sometimes I forget and it causes a failure of the node 4 CI
build, but really it's not that big of a deal. TypeScript handles the rest of
the JS stuff, and the project doesn't use enough of the node API for those
differences to matter. Other projects may different, but I think the right
call is to drop support for old node versions when maintaining them is hard or
because nobody is using them, not simply because they're old.

I want to use open source projects at work, not just in side projects, and at
work we're on node 6 and always lag behind the latest node release by some
amount, partly because upgrading node is a real project. We're a startup, not
a massive enterprise, but it's still pragmatic to focus on real work instead
of upgrading our dependencies all the time. If all of the open source projects
out there only supported node 8, I think it would make them much less useful
in the real world.

~~~
Zarel
Why not just polyfill `Array.prototype.includes`? That's what my project does
when the only features we care about missing from an old release are
polyfillable.

    
    
        Object.defineProperty(Array.prototype, 'includes', { // eslint-disable-line no-extend-native
          writable: true, configurable: true,
          value: function (object) {
            return this.indexOf(object) !== -1;
          },
        });
    

Or if you're sure you and your libraries don't use any bad coding practices,
you could even do:

    
    
        Array.prototype.includes = function (object) { // eslint-disable-line no-extend-native
          return this.indexOf(object) !== -1;
        }

~~~
alangpierce
That's what I'd do in an application, but it's bad manners to modify the
global Array.prototype from a library, or to expect your parent application to
provide such a polyfill, so usually it's best to just avoid polyfills in open
source libraries.

------
seepel
I’ve noticed this problem in the npm ecosystem pertaining to typescript
typings. Typescript is evolving really quickly, each new release allows you to
be more expressive, and there are stricter and stricter settings to take
advantage of. It’s fairly common for a third party library’s typings to be
incompatible with new typescript settings. The problem is that maintainers are
reluctant to add support in the name of backwards compatibility. The only
solution I’ve found in some cases is to completely override the library’s
typings myself locally.

------
amluto
Outsourcing LTS support to (mostly) vendors is a big deal for Linux. When I
write Linux code that needs a backport, I'll put a little bit of effort into
making it easyish. Maybe I'll answer questions about backporting and try, on a
not-very-much-effort basis, to help. This makes it way easier to keep the code
clean.

------
bitL
I think a reasonable business model would be to have original dev(s) push new
versions and outsource LTS to some commercial organization, even with dual
free/open source license for new releases and commercial one for support. If
users don't want to pay for support, project is going to be dead in a few
years anyway unless somebody wins a lottery/mines *coins/gets large
inheritance $ etc.

