Re: Can we enforce beta release for the freeze

FWIW I agree that freeze should apply to tarballs, i.e. any features or UI changes not in a tarball release by the beta tarball deadline ought to be delayed until the next release cycle. Dropping major changes a week later isn't fair to Shaun and anyone else working on documentation. But that's pretty harsh.

On the other hand, a solution that requires cloning Georges is not really a solution....

On Tue, Feb 23, 2021 at 1:53 pm, Emmanuele Bassi via desktop-devel-list <desktop-devel-list gnome org> wrote:
In the end, though, releases are manual labour; only the maintainer can say: "okay, this is good enough for other people to use" (where "people" defines different audiences depending on the stage of the development cycle). No amount of automation is going to solve that because if it did we would not need per-project maintainers in the first place, and we would only need people reviewing code and pressing the "Merge" green button.


I think we *could* automatically tag the .alpha .beta .rc and .0 tarballs, since I expect these to be created at specific predetermined times regardless of whether the code is "ready" or not. This would solve Shaun's problem. It would require a bunch of infrastructure work, though. We would lose manually-written NEWS files. But automation would probably not be able to handle library versioning, like libtool C:R:A or the meson equivalent, so maintainers would need to handle that manually in advance.

For stable releases after .0, I agree only a human can judge when a release is required.

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