On Wed, Feb 26, 2020 at 8:05 PM Robert-André Mauchin <zebob.m@xxxxxxxxx> wrote:
>
> 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.
>
You don't use Release for upstream versioning, even for snapshots. For
your examples:
* 0-0.1.beta.2 -> 0~beta.2-1
* 0-0.1.20120225gitd6c789a -> 0~git20120225.d6c789a-1
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
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
