On Monday, 24 February 2020 17:48:36 CET Pierre-Yves Chibon wrote:
> However, for the release field, we are struggling a little bit more, two
> options are more appealing to us:
>
> A) The release field is automatically generated using two elements:
> - the number of commits at this version
> - the number of builds at this commit
> - the dist-tag being added after them
> The release field would thus look like:
> ``<number of commit at version>.<number of build at commit>%{dist}``
>
> So we could have: (A, B, C and D being different commits)
> A -- version: 0.9 -- release: ?
>
> |
>
> B -- version: 1.0 -- release: 1.0
>
> |
>
> C -- version: 1.0 -- release: 2.0
>
> |
>
> D -- version: 1.1 -- release: 1.0
>
> A rebuild of the commit D, would lead to a release 1.1 (assuming the first
> one succeeded)/
>
> Pros:
> - Easy to replicate locally
> - Every changelog entry can be mapped to a `version-release` (No changes to
> the packaging guidelines)
> - Allows triggering two builds from the same commit without any manual
> change (simplifies mass-rebuilds)
> - Easy to link a certain build with a specific commit
> - Easy to “guess” the next release value before triggering the build
>
> Cons:
> - Old packages which are no longer receiving upstream releases may need
> special care (for example if they are at the release -48 but only had
> 45 commits leading to this)
> - Relies on information from the build system for the build number (but
> can be closely simulated locally since the <n_build> info is only used for
> rebuilds)
> - Upgrade path may be problematic if Fn is upgraded to version X with
> one commit while Fn-1 is upgrade to version X with 2 commits (or more)
>
> B) The release field is automatically generated taking existing builds in
> all current Fedora releases (ie: rawhide, Fn, Fn-1...) into account. This
> means for builds of the same epoch:version, find a new release that (if at
> all possible) ensures upgradability from older Fedora versions to newer
> ones, adhering to the structure of a release tag documented in the
> Versioning Guidelines[1]. Going from the (RPM-wise) "latest build" that the
> new one should surpass, this can mean bumping in the front (`pkgrel`) or
> the back (`minorbump`).
>
> This allows packages from "very stable" upstreams who haven't released in
> years to still benefit from automatically generated releases.
>
> The following examples would use a macro for the release field as outlined
> in a separate document[2].
>
> Example #1 ("normal" release progression):
> Rawhide has: 2.0-1.fc32
> F31 has: 1.0-1.fc31
> F30 has: 1.0-1.fc30
>
> Next release in F31: 1.0-2.fc32
>
>
> Example #2 ("hotfix" in an older release, selected by an alternative macro
> (or option) in the spec file):
> Rawhide has: 2.0-1.fc32
> F31 has: 1.0-1.fc31
> F30 has: 1.0-1.fc30
>
> Next release in F30: 1.0-1.fc30.1
>
> Example #3 (pre-release, selected by an alternative macro (or option) in
> the spec file):
> Rawhide has: 2.0-1.fc32
> F31 has: 1.0-1.fc31
> F30 has: 1.0-1.fc30
>
> Next release in Rawhide: 3.0-0.1.20200224git1234abcd
>
>
> Pros:
> - Allows triggering two builds from the same commit without manual
> intervention
> - Emulates what many maintainers do manually today for most use cases
> - Can cater for pre-releases (e.g.: by offering different macros or macro
> options for the different use cases)
>
> Cons:
> - Needs the build system for information about builds in this and other
> Fedora versions
> - Not easy to reproduce locally because we don’t have machine-consumable
> knowledge about other builds in e.g. the dist-git repo
> - Does not allow to generate changelog entries with `version-release`
> information for all commits (and this will require a change in our
> packaging guidelines)
>
>
> So these are the results of our current investigations, we are very much
> eager to get your feedback on them and even more eager if you have ideas
> on how to approach/solve some of the challenges mentioned here.
>
>
> Looking forward for the discussion,
>
> Pierre
> For Adam, Nils and myself
>
>
>
How would that work with "complex" releases? For example release containing
prerelease info like 0.1.beta.2 or 0.1.20120225gitd6c789a? Many Go package
have no version, so depend heavily on the Release tag to signal what is the
snapshot date and git commit packaged.
Best regards,
Robert-André
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
