For upstream testing of ceph-volume (if it
existed outside ceph.git) you'd simply install it with pip.
Like, e.g., setuptools? Always use the latest version, and you're fine?
Seriously, this would be OK if the ceph-volume maintainers ensure that
every new release is thoroughly regression-tested against all stable
versions of Ceph that are in maintenance at the time and agree not to
roll out any non-backward-compatible features (?).
I recall that with ceph-deploy we did get into a situation where the
latest version did not support hammer, so hammer users could not simply
grab the latest version of ceph-deploy. (I guess that has been fixed in
the meantime?) Users had to "know" which version played nice with hammer
and grab that one specifically. Also, whatever bugs were in that
version, they were stuck with because nothing is backported.
I suppose the Ceph project could do the same - just maintain a single
codestream ("master") and cut releases from time to time. It would be a
lot simpler! And if a distro wanted to backport fixes to a previous
release, nothing to stop them, right? But for some reason the Ceph
project goes through the trouble to maintain multiple codestreams. And
doesn't the Linux kernel project maintains stable branches, too?
Maintaining stable branches is a lot of work, so there must be good
reasons for it. One reason I can think of is that it becomes possible to
implement non-backward-compatible features in mainline/master, yet folks
who value stability (i.e. distros and the vast majority of users) can
continue to use the older codestreams and benefit from bugfixes that get
backported.
Nathan
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
