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?
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
