Rolling release branch

[Tim Janik <timj gnu org>]

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.