regardless of whether a fixed ROS release cycle should *in general*
be tied to the Ubuntu release cycle, I believe for any 2.0-ish changes
a new ROS distribution should be released only when it is deemed
ready by the community, not when some cycle has finished.
In particular the release of Groovy and the introduction of catkin were
largely influenced by an urge to keep up with the 6 month release cycle,
and as a result the release was made in a state that passed only a minimal
definition of readiness (builds and tests pass, tutorials ready).
For such large changes, I think the community would benefit if any fixed
release cycle were discarded and a release was delayed until
Quality Assurance and community opinion are sufficient to declare a
distribution as ready for release.
Also, fixed dates for future distributions seem more appropriate where a
enough set of maintainers exist such that the effort that goes into the next
distribution is predictable. For other open-source
projects, it seems more common to just work on the next distribution
to a roadmap of planned changes, and to release whenever that is
*ready*, be it
after 6 months or 18 months.
With Willow Garage changing, maybe the fixed cycle length model is not that
useful anymore, given the package maintainership situation
So I somewhat agree to Thomas Moulard and Vincent in that ROS should
choose it's own pace
depending on the circumstances, and that there is no benefit in planning
2 years ahead.
I would welcome a decision that cares less about the amount of months or the
synchronity with Ubuntu cycles, but more about the quality of
distributions and the
community process, in particular for large changes.
On 31.05.2013 12:24, Thomas Moulard wrote: > Hello there,
> I have a very naive question: why should ROS release cycle be tied to
> Ubuntu release cycle?
> I think that ROS should adopt its own pace depending on the resources
> at hand. A one year
> release cycle for instance may be enough.
> Then, I think that OSRF should just stop building Debian packages for
> all distros except the next
> one (aka Ubuntu 13.10 Saucy as of today).
> It will greatly reduce the pressure on the release team, on the
> buildfarm and the only thing lost
> is that there will be only *one* version of ROS per Ubuntu distribution.
> It does not seem such an important loss to me. The choice of your
> Ubuntu version will be tied
> to the choice of your ROS version but this is the case for *all* the
> other packages you have at hand...
> It may have been the case at the beginning when ROS was a complete
> sandbox in /opt but now that Boost and
> other 3rd party packages are pulled from system dependencies there is
> little gain of keeping this system IMHO.
> Just to be clear: it does not mean that /less/ distributions will be
> supported. It means that /less/ distributions
> will be *updated*.
> This scheme ensures that there will be *one* ROS release available for
> *every* Ubuntu distribution from the
> day they are released until their EOL.
> This includes very long term support such as Ubuntu LTS server (5
> years) which is, IMHO, very needed for
> ROS versions which are embedded into robots.
> Has this alternative strategy ever been discussed on your side?
This message was posted to the following mailing lists: