Re: Rolling release branch

[Tim Janik <timj gnu org>]

Hey Damien,

thanks for your comments (also the additional IRC discussions).

I've created a 0-12-x branch now for making 0.12.xxx releases.

The configure.ac version numbers on master are now reset to 0.0.0-dev,
no releases should ever be made from that.

While the 0-12-x branch should be a lot more stable than master, it may still
contain intermediate changes or lack automake, etc updates while between releases.
So to build a particular *stable* version, you're best of to build either from
tarballs or from git tags. Releases are always tagged (with annotation, as used
by git describe), e.g. the newest tarball is built from:

* ac2f0 (tag: 0.12.0-beta.1) # NEWS: add news for 0.12.0-beta.1 (30 hours ago)

So by pointing build scripts at a release tag like 0.11.0 or 0.12.0-beta.1, a
particular release can be built that is guaranteed to correlate with the
correspondingly versioned tarball.

In case you don't want to follow the latest release tags manually, I'm updating
my release scripts to also update a 'wip/latest-stable' branch tip. The 'wip'
part indicates that it'll see non-linear updates.

To sum up, when building releases from git, either use tags:

0.10.0          Release beast-0.10.0.tar.xz             f25a830ed4c869
0.11.0          Release beast-0.11.0.tar.xz             548988c4294b26
0.12.0-beta.1   Release beast-0.12.0-beta.1.tar.xz      ac2f0b3e0361f2

Or use this auto-updating branch:

wip/latest-stable                ac2f0b3e0 NEWS: add news for 0.12.0-beta.1

In the future, wip/latest-stable may point to mostly non-beta versions.
Depending on whether we consider a particular -beta or -rc version more stable
or fixed than the previous version wip/latest-stable points at.



On 13.03.2018 15:00, Damien Moody wrote:
> Hey guys,
>
> I think it's awesome you're putting this much thought into it and are so
> willing to accommodate Gentoo. (Or specifically, Gentoo Studio, my
> distro based on Gentoo for pro-audio applications.)
>
> Gentoo ebuild developers are very much used to simply accommodating the
> release schedules of application maintainers. Each version of a package
> has its own ebuild. The ebuild scripting language has quite a bit of
> syntax to handle both release versions and live/git repos. (Note that I
> am decidedly not as l337 with this as I'd like to be!) Although Gentoo
> is a rolling release distro, it doesn't really care if individual
> applications are designed for rolling release or not.
>
> That said, I will admit I prefer a "use the simplest" approach, so
> either beast-latest or the live-stable options (options 1 and 4 below)
> get my vote. These will be the easiest for accommodating ebuild naming
> conventions. However, please do use what works the most effectively for
> you guys.
>
> Cheers,
> Damien
>
> On 03/13/2018 05:58 AM, Tim Janik wrote:
> > Hey All.
> >
> > Damien has recently started to work on packaging Beast for Gentoo.
> > Gentoo is a rolling release, so the packaging recipe ideally would
> > refer to the latest end-user consumable Beast version, i.e.
> > something that comes close to a Beast rolling release.
> >
> > Since for Beast the newest developments are regularly merged into
> > 'master', using master @ github.com/tim-janik/beast is often not
> > stable enough to build end user packages from.
> > Every once in a while, we stabilize master and fabricate a release,
> > that's probably the best version to use for packaging but isn't
> > easily scripted.
> >
> > Ideally, the packaging recipes could pick up the latest stable
> > version from Git, but I've been unable to find a well established
> > easy to use scheme for this. Despite an obvious need for this -
> > googeling for "latest stable" shows many users looking for latest
> > upstreams and every project has other means to find this out -
> > many of which can't be scripted. Lots of semi clever scripts can
> > be found around this, e.g. based on:
> >   git ls-remote --tags https://github.com/tim-janik/beast.git
> > But a tag list still needs proper sorting of release tag versions.
> > In contrast, Github sorts its "latest release" by release date [1]
> > instead of versions, which can create problems if two stable
> > branches produce releases.
> >
> > I'd welcome input (esp. from Damien) on whether providing a tarball
> > link like "beast-latest.tar.xz" in our download area is good enough,
> > or whether we should also consider a Git branch based solution to
> > this. I.e. we could maintain a branch that points to the latest
> > stable git version that can be used in the Gentoo recipes [2]. But
> > that'd be a public Git branch that after every release gets
> > non-linear updates which is mostly frowned upon.
> >
> > Other examples for public branches with rewound commits / non-linear
> > updates:
> >
> > - [3] git.git has 'next' which is rewound after every release and 'pu'
> >   (proposed updates [5]) for short lived throw-away branches.
> >
> > - [4] Git Rebasing Public Branches Works Much Better Than You’d Think
> >
> > - Projects often use wip/<feature> or <feature>-wip for work in progress
> >   branches that are rebased and published.
> >
> > None of the above fit a rolling release branch pointer exactly.
> > Adding such a branch to Beast means it must be very clearly labeled as
> > seeing non-linear updates, which means people should never check it out
> > and base their own work/branches of it. But it'd be perfectly fine to use
> > as a commit pointer *once* for checkouts and package or CI builds.
> >
> > Since wip/pu/next don't really fit the purpose well, I'm open to
> > naming suggestions, here are a few ideas at solutions:
> >
> > 1) https://beast.testbit.org/pub/beast-latest.tar.xz - always links
> >    to the latest release tarball
> >
> > 2) 'repoint/rolling-stable' git branch: points to latest stable branch,
> >    could include not yet released fixes on the stable branch.
> >
> > 3) 'noff/latest-release' git branch: points to latest release tag,
> >    'noff' is abbreviation for non-fast-forward as in git-push(1)
> >
> > 4) 'live/stable-branch' git branch naming variant, at one cycle points
> >     to release-17-x, later release-18-x and so on.
> >
> > [1] https://stackoverflow.com/questions/22822586/swap-latest-release-on-github
> > [2] https://devmanual.gentoo.org/eclass-reference/git-r3.eclass/index.html#lbAE
> > [3] https://git-scm.com/docs/gitworkflows
> > [4] https://redfin.engineering/git-rebasing-public-branches-works-much-better-than-youd-think-ecc9a115aea9
> > [5] 
> > https://git.wiki.kernel.org/index.php/GitFaq#refs.2Fheads.2Fpu:_does_not_fast_forward_to_branch_.27pu.27

-- 
Yours sincerely,
Tim Janik

https://testbit.eu/timj
Free software author.