On Wed, 2020-02-26 at 23:07 -0500, Neal Gompa wrote:
> 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
This doesn't work reliably as the string "git" can't be sorted sensibly
between e.g. "alpha", "beta", "rc" tagged upstream pre-releases,
because a git commit can come from anywhere on the timeline. Here's
what the Versioning Guidelines[1] start off with: "If you wish to
package a prerelease version and are confident that you will need to
package only tagged releases and not any snapshots until the next
release, you MAY make use of RPM’s tilde (‘~’) notation."
Nils
[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_versioning_prereleases_with_tilde
--
Nils Philippsen "Those who would give up Essential Liberty to
Software Engineer purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
old: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
_______________________________________________
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
