On Mon, Feb 24, 2020 at 06:13:21PM +0100, Miro HronĨok wrote:
On 24. 02. 20 17:48, Pierre-Yves Chibon wrote:
> However, for the release field, we are struggling a little bit more, two options
> are more appealing to us:
Can we please have a "git is the only source of truth" version of this? I.e.
"Compute the release field from the number of commits since the last version
change" in the document. It seem to only have one con (breaks if two builds
are triggered from the same commit) which is the status quo.
It has another con which is indeed not mentioned in this section but in the next
one (n_commits+n_build) (I've fixed that).
Upgrade path may be problematic if you update Fn to a version in less commit
than the update for Fn-1 (ie: you update F32 to 1.0 in 1 commit and update F31
to 1.0 in 2 commits, suddenly you have F32 with 1.0-1 and F31 with 1.0-2).
If you need to rebuild for a libpingouisawesome soname bump, you just
do an
empty commit with the explanation.
If you merge that empty commit to a branch that did not need it, it would
have a bogus changelog entry (status quo). If you care, you would not merge
but cherry-pick anything thta comes next (which is now much easier given the
benefit of not having the %changelog and release).
With the proposed solution that includes "successful build count" you always
bump and build even if it is not needed and also you make the release number
depend on a specific build system, which I think is kinda wrong.
One of the benefit of the approach using number of commits + number of builds
(when it's > 1) is that mass-rebuild could be made even simpler and faster.
Instead of doing git commit + koji build, you would simply do koji build.
Pierre