6 ms·

Stop supporting old releases

97 points by okket 9y ago

tscs37 9y ago
> 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.
- nirvdrum 9y ago
  Agreed. I'd go a step further and say requiring constant upgrades to get even security patches makes semantic versioning essentially pointless. It doesn't really matter that the version number indicates an API change if my only choice is to upgrade or get completely left behind. I hit this a lot of with the Rails ecosystem. In many cases, upgrading to the latest version of some gem was more disruptive or riskier than keeping the current version and patching myself. But some devs will also yank old versions making that tricky as well. Rails itself, however, does a remarkable job of providing both patches and backports for security issues. I'd like to extend a big thanks to anyone that does expend extra effort to provide a solution to existing users. When having to deal with a security issue, nothing's more frustrating than not being able to upgrade immediately because doing so entails API changes or incompatible dependency graph changes.
- ProblemFactory 9y ago
  > 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 9y ago
    Yeah it's basically the only way you should be doing LTS.
deleted 9y ago
[deleted]
antirez 9y ago
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 9y ago
  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.
  - jt2190 9y ago
    Here's a link to a video where the Angular team answers the LTS question: https://www.youtube.com/watch?v=rboo-s9yq8s&feature=youtu.be&list=PLOETEcp3DkCoS_2cW205cfRGl-Xp5jw4K&t=2192 https://www.youtube.com/watch?v=rboo-s9yq8s&feature=youtu.be...
  - gaius 9y ago
    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 9y ago
      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 9y ago
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 9y ago
  > 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 9y ago
    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 9y ago
>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 9y ago
  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.
- tdbgamer 9y ago
  Sounds like the author picked a very specific case and assumed all LTS was that way. I've personally always understood LTS to be a feature freeze with only security patches being back ported. I've worked at places that did stuff like the author suggests without pinning versions, and it always just ends up with some unlucky person spending their weekend fixing a dumb bug cause by an upgrade. LTS is the reason we can all sleep soundly knowing our code won't spontaneously break, so I'm extremely grateful to the hard work everyone puts into it.
3pt14159 9y ago
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.
- Kenji 9y ago
  If you need the latest OS version for your software to run, you're doing software design wrong. Except for very special features, software should run all the way to 10-20 years old OS versions. And if it doesn't, you should have abstractions in place such that all you have to do is change a dll and be good to go again. Why the hell would a high level language like Ruby have such deep OS dependencies? Use the goddamn POSIX standard and you'll be compatible to every single important OS that's come out in the last decades, except for Windows which can be made POSIX compatible with a few layers of abstraction.
- pjc50 9y ago
  > 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. Sure, this is bad - but if they are to be OS updateable then the OS has to guarantee it won't drop support for things, or increase significantly in size because then it won't for in the flash. Enterprise customers really like LTS as a concept, but they should be made to pay for it like the article says.
bitL 9y ago
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.
amluto 9y ago
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.
alangpierce 9y ago
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 9y ago
  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 9y ago
    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 9y ago
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.

97 points by okket 9y ago

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

nirvdrum 9y ago
Agreed. I'd go a step further and say requiring constant upgrades to get even security patches makes semantic versioning essentially pointless. It doesn't really matter that the version number indicates an API change if my only choice is to upgrade or get completely left behind. I hit this a lot of with the Rails ecosystem. In many cases, upgrading to the latest version of some gem was more disruptive or riskier than keeping the current version and patching myself. But some devs will also yank old versions making that tricky as well. Rails itself, however, does a remarkable job of providing both patches and backports for security issues. I'd like to extend a big thanks to anyone that does expend extra effort to provide a solution to existing users. When having to deal with a security issue, nothing's more frustrating than not being able to upgrade immediately because doing so entails API changes or incompatible dependency graph changes.
ProblemFactory 9y ago
> 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 9y ago
  Yeah it's basically the only way you should be doing LTS.

deleted 9y ago

[deleted]

antirez 9y ago

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 9y ago
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.
- jt2190 9y ago
  Here's a link to a video where the Angular team answers the LTS question: https://www.youtube.com/watch?v=rboo-s9yq8s&feature=youtu.be&list=PLOETEcp3DkCoS_2cW205cfRGl-Xp5jw4K&t=2192 https://www.youtube.com/watch?v=rboo-s9yq8s&feature=youtu.be...
- gaius 9y ago
  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 9y ago
    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 9y ago

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 9y ago
> 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 9y ago
  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 9y ago

>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 9y ago
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.
tdbgamer 9y ago
Sounds like the author picked a very specific case and assumed all LTS was that way. I've personally always understood LTS to be a feature freeze with only security patches being back ported. I've worked at places that did stuff like the author suggests without pinning versions, and it always just ends up with some unlucky person spending their weekend fixing a dumb bug cause by an upgrade. LTS is the reason we can all sleep soundly knowing our code won't spontaneously break, so I'm extremely grateful to the hard work everyone puts into it.

3pt14159 9y ago

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.

Kenji 9y ago
If you need the latest OS version for your software to run, you're doing software design wrong. Except for very special features, software should run all the way to 10-20 years old OS versions. And if it doesn't, you should have abstractions in place such that all you have to do is change a dll and be good to go again. Why the hell would a high level language like Ruby have such deep OS dependencies? Use the goddamn POSIX standard and you'll be compatible to every single important OS that's come out in the last decades, except for Windows which can be made POSIX compatible with a few layers of abstraction.
pjc50 9y ago
> 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. Sure, this is bad - but if they are to be OS updateable then the OS has to guarantee it won't drop support for things, or increase significantly in size because then it won't for in the flash. Enterprise customers really like LTS as a concept, but they should be made to pay for it like the article says.

bitL 9y ago

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.

amluto 9y ago

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.

alangpierce 9y ago

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 9y ago
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 9y ago
  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 9y ago

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.