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