Re: Can we enforce beta release for the freeze

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/](https://pypi.org/project/gitlab-auto-release/#:~:text=GitLab%20Auto%20Release%20This%20is%20a%20simple%20Python,so%20it%20can%20create%20the%20release%20for%20you.)

Warm Regards,
Eric

On Tue, Feb 23, 2021 at 9:37 AM, Michael Catanzaro <[email protected]> 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
> <[email protected]> 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
> [email protected]
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

_______________________________________________
desktop-devel-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/desktop-devel-list