Re: Can we enforce beta release for the freeze
- From: ehock7229 protonmail com
- To: Michael Catanzaro <mcatanzaro gnome org>, Emmanuele Bassi <ebassi gmail com>
- Cc: Shaun McCance <shaunm gnome org>, desktop-devel-list <desktop-devel-list gnome org>
- Subject: Re: Can we enforce beta release for the freeze
- Date: Sat, 20 Mar 2021 14:32:35 +0000
Hi,
Noticed a question about a way to automate, GitLab CI could automate beta and stable releases for us, did some digging and found this Python package that could help with that. Don’t know it this will help any, but here is a link to that scrip.
https://pypi.org/project/gitlab-auto-release/
Warm Regards,
Eric
On Tue, Feb 23, 2021 at 9:37 AM, Michael Catanzaro <
mcatanzaro gnome org> wrote:
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.
Wellll...
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.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]