gnustep-dev
[Top][All Lists]
Advanced

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

Re: Releases


From: Ivan Vučica
Subject: Re: Releases
Date: Wed, 11 Jan 2023 10:47:09 +0000



On Tue 10 Jan 2023 at 19:43, Frederik Seiffert <frederik@algoriddim.com> wrote:

Am 10.01.2023 um 14:27 schrieb Ivan Vučica <ivan@vucica.net>:

I really would like to minimise the number of steps we have to go through by automating as much as possible.
I did. :-)

Please see my release jottings on Google Docs. They’re not formal documentation, but can be interpreted as a playbook with some reading. 

I’m not familiar with what needs to be done for releases (can you share a link to that Google Doc maybe?), but I’m wondering if released could be mostly automated on the GitHub Actions CI.

Mainly because it is a mess and it’s mainly my notes on what I did + to share with maintainers, I am not keen on making it publicly visible. If it were to be a playbook, I’d put it up somewhere in repos as proper documentation.

However, I’ve added your corporate email address to the ACL for the doc for 2.9.0/1.28.0/0.29.0 release of ~March 2021:

https://docs.google.com/document/d/1DGumTDgxGwsaamnFvJ5WI1puVHHKk2f1t7GNrwLHfi0/edit?usp=sharing

I can add other interested maintainers to these docs, but again, there’s no point in making this more visible if it’s just notes and not proper documentation.

I’ll see if I can turn this into something more widely shareable (maybe once I finally upgrade the wiki schema on the new gnustep.org machine…).


For the Android and Windows MSVC toolchains, every build on the master branch creates a pre-release on GitHub (overwriting the previous one), and then if I want to do a release I test the latest build and then simply add/edit the change log and check a box to turn it into a release (which also creates a corresponding git tag). Here’s the required Actions code:

https://github.com/gnustep/tools-android/blob/d71de40e60f71988b40610e39b5df926e6df1687/.github/workflows/ci.yml#L57-L84

In this case, the "prerelease" step will wait for the two builds (macOS and Linux) to complete, and then create a "Latest Build" pre-release on GitHub with the artifacts for the two platforms.

I think it makes sense if you’re doing binaries, but less so if most of the tedious process is actually getting documentation (release notes…) in shape, and invoking the correct commands to create the tag in the first place (using the release notes in the tag). 
--
Sent from Gmail Mobile

reply via email to

[Prev in Thread] Current Thread [Next in Thread]