Hi,
In the Storage SIG we provide different versions of Gluster. The new upstream release schedule[0] defines two different types of releases:
a. Long Term Maintenance - gets updates for ~12 months b. Short Term Maintenance - gets updates for ~3 months
The actual time depends a little on how releases are keeping their schedule (a release every 3 months). There are two Long Term Maintenance versions active at a time. The Short Term Maintenance releases provide early access to new features, and are recommended only for early adopters and users who do not mind upgrading their storage environment everye 3 months.
This makes for an interesting packaging problem. We would like our users to be able to install the Gluster packages with a command as simple as this:
# yum install centos-release-gluster # yum install glusterfs-server
Users should not need to care (or know) about the actual version they are installing. Currently Gluster 3.8 is provided by the c-r-gluster38 package, with a "Provides: centos-release-gluster = 3.8".
When I add a new c-r-gluster39 package, with a similar "Provides:", I do not want users to get the 3.9 version by default. Users should get the Long Term Maintenance versions, and only opt-in on the Short Term Maintenance version. But, on the other hand, an installed 3.9 version should be usable for other SIGs that depend on Gluster (like the Virt SIG for oVirt).
Currently I am thinking to do the "Provides:" like:
# Users can install centos-release-gluster to get the latest, but we # do not want to have 3.9 (Short Term Stable) to be selected when # users do install the virtual centos-release-gluster package. Provides: centos-release-gluster = 0.3.9 Conflicts: centos-release-gluster < 0.3.9 Obsoletes: centos-release-gluster < 0.3.9
Existing (all Long Term Stable) release packages do not have the 0. prefix:
# Users can install centos-release-gluster to get the latest Provides: centos-release-gluster = 3.8 Conflicts: centos-release-gluster < 3.8 Obsoletes: centos-release-gluster < 3.8
We do not want automatic updating/replacing of the release package in any case (might need manual intervention for major releases). The current approach works sufficiently well. Except for the potential issue where other SIGs/projects depend on 'centos-release-gluster >= 3.8'. This will not work with the 3.9 release package.
I am hoping others can suggest a more elegant solution that addresses all of these use-cases.
Many thanks! Niels