Re: Rolling release branch



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]