Query about package versioning

Vivek Goyal vgoyal at redhat.com
Thu Feb 20 18:58:58 UTC 2014


On Thu, Feb 20, 2014 at 05:39:17PM +0100, Mikolaj Izdebski wrote:
> On 02/20/2014 05:28 PM, Marcin Juszkiewicz wrote:
> > W dniu 20.02.2014 17:16, Vivek Goyal pisze:
> > 
> >> So instead of increasing release number on released branches, why don't
> >> we append additional number after dist and bump that up in released
> >> branch. So FC21 releases will look like.
> >>
> >>   kexec-tools-2.0.4-24.fc21.1
> >>   kexec-tools-2.0.4-24.fc21.2
> >>   ...
> >>   ...
> >>   kexec-tools-2.0.4-23.fc21.10
> >>
> >> That way we clearly know that FC21 was forked off master release .24. And
> >> upgradability of package will be maintained without any change of older
> >> release versions getting ahead of newer release versions.
> > 
> > %dist should be at the end.
> > 
> > So rather kexec-tools-2.0.4-23.X.fc21 where X means x-th revision of
> > fc21 package after distribution release.
> 
> That won't work if both branches already have the same release number
> and you need to bump release in older branch.  That can happen for
> example if you were fast-forwarding commits from f21 to f20 and at some
> point you need to add a bugfix only for f20.  Adding .1 after dist-tag
> will work in this case.

What is fast forwarding commits from f21 to f20. I guess you are saying
there are bunch of commits in master branch and you want to now apply
those commits to f20 branch too?

If yes, one can simply do another release on master branch if there is
a need to commit a patch in f20 only.

Say master is at kexec-tools-2.0.4-23.0.fc21 and has bunch of more commits
on top.

FC21 forks off and has kexec-tools-2.0.4-23.0.fc21 and a patch needs to
applied to FC21 only. Then one can do another release on master to avoid
any kind of upgradability conflicts.

master will be kexec-tools-2.0.4-24.0.fc22
FC21  will be kexec-tools-2.0.4-23.1.fc21

So I don't see why above will not work?

IOW, it is better to use an extra field for versioning of released
branches to avoid any kind of conflicts with master. Instead of
overloading same release field for all the branches.

Not sure why more package not follow this extra field thing. I am trying
to find out if anything is fundamentally wrong if we try to pursue this
scheme in kexec-tools pacakge.

Thanks
Vivek


More information about the devel mailing list