Time for reviewing ROS distro release cycle?

Is/was there any discussion regarding ROS distro release cycle, particularly about non-LTS?

Thanks to the 2017 metrics report we can tell that 80+% of downloads are for LTS (Indigo, Kinetic) while less than 6% non-LTS packages are fetched:

  • Indigo: 32.43 % (Long Term Support Release)
  • Jade: 2.22 %
  • Kinetic: 50.08 % (Long Term Support Release)
  • Lunar: 3.41 %

While I do not know what these figures exactly mean, I think it’s safe to say the great majority of users are using LTS.

Are we going to stick to the current release cycle? I.e. non-LTS releases on odd numbered years?

This wiki summarizes the huge discussion last time we had where we decided the current release cycle as a result. Almost 4? years passed since then, with the metrics result above, it’s worth reviewing the release cycle IMO.

Personally I support simply dropping the non-LTS and only focusing on LTS every 2 year. That way ROS core team will have more time on other important work, so do non-core package maintainers and developers. We would have less test bed opportunities for new features, but I don’t know how much we have to prioritize it now that we saw the metrics.
Maintenance effort for non-core packages that are missing in newer distros has been always an issue; we’ve recently seen topics like 1, 2. Dropping non-LTS could help.

4 Likes

+1
I agree with @130s Isaac’s opinion.
In fact, very few members seem to use the non-LTS ROS version.

It’s definitely something we might want to consider. However I’d suggest that doing this now is not the best time. Our next release, melodic, is another LTS version so it won’t make a lot of sense to make this sort of decision over a year an a half ahead of the next effected potential release.

The cited statistics have some shortcoming on making a decision like this, we’ll need to collect more information. In particular I’ll point out that we’re very early in the cycle of Lunar. It’s a relatively new distro and it’s only been available for a few months. For example in 2016 Kinetic was just at 11%. Clearly that had higher adoption than lunar does but judging adoption this early in the cycle is a little premature to say that it is not worth supporting.

There are also issues that if we only have the LTS releases we will be unable to support all Ubuntu versions as well as Fedora and Debian versions that do not line up with our release cycle. There are hardware systems that need newer kernels and other systems often for driver support and sometimes can’t run on older Ubuntu LTS releases.

However since we can’t take any action now, I would suggest that if we are to have this discussion we would wait until a little before the ‘melodic’ release when we will have close to a year’s worth of data for Lunar and start looking forward for ROS N at which time we could review it’s timing or support period.

For Ubuntu this is being addressed by newer releases of LTS distros, e.g. 16.04.3 will ship with a newer kernel and drivers as 16.04 originally did. So I don’t see a need to support for non-LTS Ubuntu distros. For Fedora and Debian that is certainly different since their newer version might not be available when a certain ROS LTS release is being prepared.

I think these two things don’t go well together. Since the statistics do have some shortcomings they should be addressed now. Otherwise when we want to revisit the decision in a year+ we might simply not have the data we need to make an informed decision.

E.g. the download numbers vary highly dependent on the number of releases and which packages are being released. That needs to be normalized for a useful comparison. Additionally it could be that many downloads are not coming from users but robots being updated or CI jobs being run. While those are certainly “using” a specific ROS distro they might skew the statistics too.

There are also other options to consider. Between LTS releases every two years we could follow a rolling release (which at the end of the two years becomes the next LTS). That way we can track newer Linux distributions when they come out. The question would be if enough users would care to use such a rolling release?

My point is that the annual metrics reports are not enough to make a decision, but that’s not the only data we will have available next spring. The download data is available for all months, not just July in the metrics reports. I will just have to pull the logs and run the analysis. If we wait until next spring we’ll have 9 months of trends instead of just the first 3 months for Lunar.

We would also likely want to do some more surveys etc about users use cases and needs for platform support. People’s planning horizons for OS support out 2 - 3 years is a lot less accurate than for the next year or two. So if we defer the survey and trend analysis until next spring/late in the melodic cycle then people will be looking only 1 or 2 upgrade cycles out instead of potentially 3 or 4 as Ubuntu Artful will be out and Ubuntu 18.04 will be well defined by then too.

I was less worried about the point in time the data for the metrics report was collected but about “what” data is collected. If the data is not sufficiently representative (as described in my comment) it might be necessary to adjust the collection before looking at the data next year.

I’m liking that idea, as it would perhaps give each upcoming LTS more time to mature and receive develoment as well as feedback from end users while at the same time making sure migration efforts are directly invested into the porting and distro adoption of the greater ROS package ecosystem.

Are there any commentaries or studies you’d suggest on how well it works in practice, say from the Debian maintainers? Or archived mailing list discussion/debates on why canonical choose follow this release strategy? Maintaining a incremental release system on moving target in active development seems like quite a bit to juggle though.

Arch Linux and Gentoo are two well-known distributions that use a rolling release. Both work well. As a Gentoo user, I think the approach works very well for a situation like Linux or ROS where you have lots of packages being updated at disparate times. The packaging infrastructure of Gentoo makes it easy to pin the entire set of installed packages to a chosen state, or specify your own “version” of the distribution if that is needed (e.g. for a bunch of servers you maintain).

Having said that, the infrastructure required to support a rolling release is not trivial and may need a significant investment in time to create.

The approach taken by Debian of having Unstable, Testing and Stable is a very good hybrid between fixed versions of a distribution and a rolling release. Although ROS has the shadow repositories, they are poorly advertised and not as well set up as Debian’s testing branch. I think that ROS would do well to follow the Debian model, and even tie it to Debian releases if possible.

Speaking both as a 15-year veteran of using Gentoo and as a developer, I find the rolling release model very useful for development. I can get more recent (or older) versions of packages easily according to my development needs. Because Gentoo’s infrastructure is very flexible, I can sometimes have two versions installed simultaneously if I need that for developing more than one piece of software at a time.

Speaking as a developer of software for ROS users, I think that the Debian model is easy to use. I can live in testing and work towards the next release knowing that everything else in the same version of ROS (as it were) will also be in that release, and that all our software will be released and usable together at a relatively known point in the future.

If I were just a ROS user (such as a robot-making company), then I imagine that I would also like the Debian model because I would know that the stable branch I would use in my products has had a significant period of testing and refining before being released and that there are firm policies to prevent breaking packages getting near it.

However all of the above is based on experience with Linux distributions where the development of packages is done significantly differently from ROS - that is, it is usually done by volunteers who are separate from the package maintainers. I think that, as Dirk pointed out when we discussed this at ROSCon, this is an important difference.

3 Likes

Where do we stand on this? The release of melodic is coming up soon, and I’m wondering if that anticipated data on Lunar is ready for our consideration.

I’m intrigued by dirk-thomas’s idea of a rolling release that pops out an LTS every few years. It seems like a good balance along the same vein of the Debian model as described by gbiggs.