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. _______________________________________________ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast