Re: Query about package versioning
Vivek Goyal wrote:
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?
Fast-forwarding is git jargon for doing a merge that simply accepts ALL
commits from master into f20, under the precondition that no non-master
commits have been made to f20. So it means you build the exact same thing
for both master and f20, and you never commit anything to f20 that isn't
merged from master (or the other way round, but you need to make sure (by
merging, if necessary) that the branches are in sync before committing to a
branch, or fast-forwarding won't work anymore, so it's easier if you always
do the merges in the same direction, which in Fedora is normally
master/Rawhide first).
For some packages, this workflow makes a lot of sense. For others, not so
much. It depends on whether you need to make changes to one branch that you
DON'T want in the other (and that it doesn't make sense to use %if
0%{?fedora} n conditionals on). But note that there are only few cases
where you want to do release-branch-only changes, normally you always want
to do the changes either only in master (which implies maintaining the
branches separately) or in both.
If you really need to maintain the branches separately, then yes, your
versioning scheme makes a lot of sense and is in fact already recommended by
our guidelines!
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bumps_for_old_branches
(Yes, Michael Schwendt has already posted that link.)
If you really need to make more changes in the release than in master (which
usually should not happen, but sometimes there's a legitimate reason for
that), this is even REQUIRED, because you MUST NOT push n+1.fc20 when
Rawhide has n.fc21, as that would break the upgrade path.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Query about package versioning
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Query about package versioning
On 02/20/2014 05:16 PM, Vivek Goyal wrote: 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. IMO it's best to do fast-forward merges between branches when possible. In particular merging mass rebuild commits is OK. In case FF merge is impossible I agree with the procedure you described. You need to increase release tag in a way that assures upgrade path and one way to do that is adding .1 after dist tag. -- Mikolaj Izdebski IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Query about package versioning
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. -- Mikolaj Izdebski IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Query about package versioning
On Thu, Feb 20, 2014 at 05:28:02PM +0100, 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.
[ Can you please keep me in To list. I don't want to scan mailing list
to figure out if somebody responded to my mail or not ]
Why %dist should be at the end? html page I referenced previously mentions
that one can use x.%{dist}.y kind of release number in select cases.
So rather kexec-tools-2.0.4-23.X.fc21 where X means x-th revision of
fc21 package after distribution release.
I think this will work too. As 23 got frozen in time and master and later
releases will always be higher. And that would not break upgradability.
Thanks
Vivek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Query about package versioning
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Query about package versioning
On Thu, 20 Feb 2014 17:28:02 +0100, 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. No. See: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bumps_for_old_branches -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
