On Thu, Feb 27, 2020 at 02:04:41AM +0100, Robert-André Mauchin 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)
> 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.
This is something that we will need to investigate and clarify a little more,
the answer may very well be: it won't, but let's investigate this first.
We are very well aware that the proposal in its current form will not address
all packages. The idea being to improve the situation for some packages, see how
this works and see how we can grow this number of packages. Reading this thread
you can already see that some packagers are not interested in such a system
regardless of how it is, which is fine, we want it to be opt-in.
Pierre
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
