Until Foxy (scheduled for May 2020) ROS 2 has been released roughly every 6 months. This was similar to how ROS 1 distributions where released before Hydro. At that point ROS 1 switched to a yearly release schedule. We are now at a similar point for ROS 2 where we plan to switch to yearly releases.
TL;DR ROS 2 release schedule post Foxy:
May 2021: G Turtle: non-LTS release, supported for 1.5 years
May 2022: H Turtle: LTS release, supported for 5 years
May 2023: I Turtle: non-LTS release, supported for 1.5 years
May 2024: J Turtle: LTS release, supported for 5 years
and so on, alternating annually between LTS and non-LTS releases
Note that Foxy is planned to be supported for 3 years (see ros-infrastructure/rep#217) which is a gradual ramp up from the 2 years of support from Dashing.
I think the LTS releases should be 3 years, so that we don’t end up in situations were maintainers are supposedly maintaining 3 LTS distributions and a non-LTS distribution at one time.
Having 2 LTS distributions overlapping makes sense and is worth the extra effort, but 3 at once and also non-LTS is alot to deal with and my feeling is some maintainers (e.g. probably me in that bucket) will just cease to maintain the oldest to make the time burden more practical (or just not attempt non-LTS, which is the opposite non-LTS issue we had in ROS1). I’ve already started doing that with Kinetic because of Melodic, Dashing and Eloquent as my “primary concerns”. It is very convinient that for C++ nothing changes (of note) between Kinetic and Melodic if you already made the TF2 transition so I direct Kinetic users to the Melodic branch. If that wasn’t true, like in 4 actively developed ROS2 distros, that would be less than ideal and somewhat undercut the meaning of LTS outside the core tools.
I think there’s a balance to be struck, and at least from my anecdotal experience, 3’s about my limit to maintain and also continue to develop.
I think there is a lot of value in having LTS releases for industry (5 year support), but I also understand the maintenance concerns.
What is currently the reasoning for having yearly new releases?
Would it be possible to spread releases out more (bi-yearly?), or what are the reasons not to do it?
The one thing I can think of, is that development slows down this way, so new ideas and features might take longer to end up in ROS 2, but you can’t have it both ways.
Perhaps the definition of “support” needs to be more detailed. For example, providing new features of a package on every currently-supported version of ROS 2 is a different level of work from doing new features for the latest release only and providing all bug fixes on all releases, and again that is different from just providing critical bug fixes on anything that is not the latest release.
@kyrofa Could you chip in with exactly what “support” means for an Ubuntu distribution that is not the latest?
Whoa, get out of my head @gbiggs, I was coming here to say exactly that. The concerns here are well-founded, but only if your concept of support is “I must get all features back into all supported versions.” It doesn’t need to be that way, and in my humble opinion, indeed shouldn’t be that way.
In Ubuntu, once a release is considered stable, getting changes into it goes through the SRU (Stable Release Update) process. Not only do new features of a given package not generally get back into a stable release, it’s actually against that policy. Ubuntu values stability above all else. To get a change through SRU, it generally either needs to be a bugfix or a security fix. New features go into the next Ubuntu release.
If you’re willing to change your view of support to include security and critical bugfixes for all supported releases, but only get new features into the latest release (or even the development release), not only will it save you work, but it will also provide for a more stable product for your users. Of course, in trade they give up the latest features. But if they wanted the latest features, perhaps they’d be tracking the latest ROS release.
This, I think, is the most important point. If someone wanted the latest features in a package they probably wouldn’t still be using Kinetic. They’re probably still using Kinetic because they want stability while they prove their product for release - but they do need critical bugs and security problems fixed.
In my experience a common request along these lines is of the form: I want to use the oldest, most stable platform that I can, but I’d like you to incorporate into that stable platform all the bleeding-edge improvements to the particular packages that I care about.
Oh and please also support me while I integrate all my own custom developments into it, which I’m not going to tell you about other than when your updates break my stuff
This. In my experience it boils down to inertia: when you have an assortment of laptops/robots on some Ubuntu/ROS combo with things working, the only incentive to upgrade is new features that you can’t live without. Much better if these are backported Add on top “decentralized” management by a mix of researchers that don’t care about most of the underlying tech…
Changing the underlying ROS distribution typically requires significant quality assurance activities. Nobody likes a product to degrade for no appreciable customer benefit (despite the many attempts by the IT industry to reduce our quality expectations ;-).
Moreover, some ROS distribution changes imply Linux distribution changes. For example, kinetic only supported Ubuntu up to 16.04, but melodic required at least 17.10, which isn’t LTS, or 18.04, which is. Naturally, changing Linux distributions causes even more quality assurance to be necessary.
Therefore, it would be ideal if each new ROS LTS release would support at least one Linux LTS version which was released at the time of the previous ROS LTS release.
Btw, companies which require this typically pay for it. For example, Canonical offers long-term support for Ubuntu for much longer than their standard LTS support durations, if you’re willing to pay for it. The price isn’t even that high (but you will have to ask them directly, this kind of stuff is confidential).
+1 from me on that. I think many people have been surprised in the past that rather significant changes were made after a release (though mostly in add-on components like move_base).
We understand that this would be nice to have but please read the rational provided in the REP why that is not feasible:
A single ROS 2 distribution only targets one Ubuntu LTS.
The rationale is that supporting two LTS versions - which means 2-year-different versions of upstream dependencies - is a tremendous overhead and sometimes even impossible.
Add on top “decentralized” management by a mix of researchers that don’t care about most of the underlying tech…