Up to now the glusterfs and hekafs versions and releases have been the same for f16 and rawhide, i.e.: glusterfs-3.2.4-1.x86_64.fc16.rpm, glusterfs-3.2.4-1.x86_64.fc17.rpm, hekafs-0.7-16.x86_64.fc16.rpm, and hekafs-0.7-16.x86_64.fc17.rpm.
I did that because the source, thus far, is exactly the same for both f16 and rawhide. In f16 and rawhide both glusterfs and hekafs used sysv init.d scripts.
Now for rawhide I'm going to switch to systemd. I know I can't switch to systemd for f16, so the question is, what scheme should I used for the release numbering?
One thought I had was to 'leapfrog' increment the release numbers. I already have: glusterfs-3.2.4-1.x86_64.fc16.rpm and glusterfs-3.2.4-1.x86_64.fc17.rpm. Then for the systemd version then I'd go to glusterfs-3.2.4-2.x86_64.fc17.rpm. And if I need to respin glusterfs I'd use glusterfs-3.2.4-3.x86_64.fc16.rpm and glusterfs-3.2.4-4.x86_64.fc17.rpm.
I.e: f16 rawhide current 3.2.4-1.fc16 [i] 3.2.4-1.fc17 [i] new... 3.2.4-2.fc17 [s] 3.2.4-3.fc16 [i] 3.2.4-4.fc17 [s]
([i] means init.d, [s] means systemd)
Alternatively I could just add a character to the first release using sytsemd for rawhide, e.g. 's'. Then I'd have the existing glusterfs-3.2.4-1.x86_64.fc16.rpm and glusterfs-3.2.4-1.x86_64.fc17.rpm, and glusterfs-3.2.4-1s.x86_64.fc17.rpm for the new systemd version. And for a respin then I'd just use systemd going forward for rawhide, and I'd use glusterfs-3.2.4-2.x86_64.fc16.rpm and glusterfs-3.2.4-2.x86_64.fc17.rpm.
I.e: f16 rawhide current 3.2.4-1.fc16 [i] 3.2.4-1.fc17 [i] new... 3.2.4-1s.fc17 [s] 3.2.4-2.fc16 [i] 3.2.4-2.fc17 [s]
Whichever I go with I'd do the same thing for hekafs.
Thoughts?
On Mon, 31 Oct 2011 09:01:33 -0400 "Kaleb S. KEITHLEY" kkeithle@redhat.com wrote:
f16 rawhidecurrent 3.2.4-1.fc16 [i] 3.2.4-1.fc17 [i] new... 3.2.4-1s.fc17 [s] 3.2.4-2.fc16 [i] 3.2.4-2.fc17 [s]
Whichever I go with I'd do the same thing for hekafs.
Seems fine. For HekaFS we do have another option, which would be to bump the minor release:
hekafs-0.8-1.x86_64.fc17.rpm
I'm not quite ready to say it's 1.0 until we do something about quota and shed the cloned transport bits (which requires getting the SSL patch all the way into GlusterFS), but 0.8 and 0.9 are still valid.
On Mon, Oct 31, 2011 at 09:01:33AM -0400, Kaleb S. KEITHLEY wrote:
Up to now the glusterfs and hekafs versions and releases have been the same for f16 and rawhide, i.e.: glusterfs-3.2.4-1.x86_64.fc16.rpm, glusterfs-3.2.4-1.x86_64.fc17.rpm, hekafs-0.7-16.x86_64.fc16.rpm, and hekafs-0.7-16.x86_64.fc17.rpm.
I did that because the source, thus far, is exactly the same for both f16 and rawhide. In f16 and rawhide both glusterfs and hekafs used sysv init.d scripts.
Now for rawhide I'm going to switch to systemd. I know I can't switch to systemd for f16, so the question is, what scheme should I used for the release numbering?
If you are planning only minor updates in F-16, you can probably use the description on "Minor release bummps for old branches" [1]. The result would than be something like:
glusterfs-3.2.4-1.x86_64.fc16.rpm - base version with sysv-init glusterfs-3.2.4-2.x86_64.fc17.rpm - updated version with systemd-unit
Bugfixes for F-16 can be done as patches/backports and the new nvr would be glusterfs-3.2.4-1.x86_64.fc16.1. For F-17/Rawhide it would just be in the new upstream version, or updated release as in glusterfs-3.2.4-3.x86_64.fc17.
Personally I would favour this, but it will involve maintaining a seperate branch for the sysv-init version of the package. The main advantage is that the F-17/Rawhide spec will be kept simple, and there is no need to remove the %if statements once there is no sysv-init version available anymore. It will be impractical if you are planning big(ger) updates that would need a real version bump.
Cheers, Niels
[1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bump...
On Mon, 2011-10-31 at 09:01 -0400, Kaleb S. KEITHLEY wrote:
Up to now the glusterfs and hekafs versions and releases have been the same for f16 and rawhide, i.e.: glusterfs-3.2.4-1.x86_64.fc16.rpm, glusterfs-3.2.4-1.x86_64.fc17.rpm, hekafs-0.7-16.x86_64.fc16.rpm, and hekafs-0.7-16.x86_64.fc17.rpm.
I did that because the source, thus far, is exactly the same for both f16 and rawhide. In f16 and rawhide both glusterfs and hekafs used sysv init.d scripts.
Now for rawhide I'm going to switch to systemd. I know I can't switch to systemd for f16, so the question is, what scheme should I used for the release numbering?
Honestly, I wouldn't fuss about keeping release numbers in sync - as soon as someone does the first Fedora 17 mass rebuild, they'll be out of sync anyway.
Cheers, Mark.
-
Jeff Darcy -
Kaleb S. KEITHLEY -
Mark McLoughlin -
Niels de Vos