build(release): two different release workflows overwrite each other upon release about universal-android-debloater-next-generation HOT 9 CLOSED

I'd like a comprehensive but clear changelog, and it should be consistent as well.

@AnonymousWP we'll be using GitHub's auto-generate feature, so it will be as clear & consistent as PR titles.

I prefer the second option when it comes to borked releases. First and third options may be confusing to users as it may suddenly disappear and they wonder what happened to v1.0.0 for example. For the sake of transparency too. Let me know.

Okay, agreed on "issue a hotfix and keep the borked release but add warnings".

from universal-android-debloater-next-generation.

Currently, the release.yml action (henceforth simply called "Action") creates a release if a git tag is pushed, which is what was done in #153. Both of the other developers approved changes.

Then for v1.0.0, a non-developer (@AnonymousWP) created the release, and they may not have been aware of this particular Action being changed. Or perhaps because of hurriedness in the moment we forgot about this and created a release via GitHub frontend with the "Create new tag on publish" option.

Obviously, that created a new tag, which the Action then, well, acted upon.

So fixing this issue can be done in two ways: either we modify the Action yet again to undo #153, or we establish a (human) workflow for releases. I recommend the following steps at the very least:

• A release checklist document outlining all the processes, behaviours, and whatever else that may be worth remembering
  This will ideally be looked upon by several people — both developers and otherwise
• Appointing 1 or 2 "release managers" who create & maintain releases
  They are also be held responsible for making sure the checklist is kept up-to-date, and can optionally adjust relevant Actions for their benefit. Or they can communicate with developers to do it on their behalf.
• A policy on how we should deal with borked releases
  • Do we replace artifacts & checksums with the corrected versions; or
  • Do we issue a hotfix and keep the borked release but add warnings; or
  • Do we issue a hotfix and remove the borked release from GitHub (this is most common I believe)

from universal-android-debloater-next-generation.

I'm all for automation. However, it should be well-documented.
We must also fix the release workflow to auto-generate with the new format instead of inserting the changelog. I don't know if that's possible, and if not, then manually triggering the release workflow would be best.
We also have to definitely create a process for releases, which would probably take form in a release preparation PR, which would bump rust package version and cargo.lock, so we can make sure everything is right and working, before creating the release.
Release then would be merging that pr, and creating the release manually, or if done automatically, adding the tag and letting github actions work it's magic

from universal-android-debloater-next-generation.

Currently, the release.yml action (henceforth simply called "Action") creates a release if a git tag is pushed, which is what was done in #153. Both of the other developers approved changes.

Then for v1.0.0, a non-developer (@AnonymousWP) created the release, and they may not have been aware of this particular Action being changed. Or perhaps because of hurriedness in the moment we forgot about this and created a release via GitHub frontend with the "Create new tag on publish" option.

Obviously, that created a new tag, which the Action then, well, acted upon.

So fixing this issue can be done in two ways: either we modify the Action yet again to undo #153, or we establish a (human) workflow for releases. I recommend the following steps at the very least:

• A release checklist document outlining all the processes, behaviours, and whatever else that may be worth remembering
  This will ideally be looked upon by several people — both developers and otherwise

• Appointing 1 or 2 "release managers" who create & maintain releases
  They are also be held responsible for making sure the checklist is kept up-to-date, and can optionally adjust relevant Actions for their benefit. Or they can communicate with developers to do it on their behalf.

• A policy on how we should deal with borked releases

  • Do we replace artifacts & checksums with the corrected versions; or
  • Do we issue a hotfix and keep the borked release but add warnings; or
  • Do we issue a hotfix and remove the borked release from GitHub (this is most common I believe)

I'm also for automating, but I'd like a comprehensive but clear changelog, and it should be consistent as well.

I'm planning to create a branch where we document this checklist (and a policy about how we deal with borked releases) and where every org member can contribute/push to. As for the second point regarding 'release managers': I think this should be either me or one of the @Universal-Debloater-Alliance/developers; doesn't really matter who of us it is, as long as we know about these guidelines and the process we need to follow. I don't think this requires an extra GitHub Team, but let me know if you don't agree.

I prefer the second option when it comes to borked releases. First and third options may be confusing to users as it may suddenly disappear and they wonder what happened to v1.0.0 for example. For the sake of transparency too. Let me know.

a release preparation PR, which would bump rust package version and cargo.lock, so we can make sure everything is right and working, before creating the release.

@Frigyes06 This is usually the case when there's a dev branch (which we got rid of) and with a new release, everything from dev is pushed to main. ReVanced/revanced-patches#2707 is a good example of that, but that wouldn't work for us as we don't use that strategy anymore. Or did you mean something else?

from universal-android-debloater-next-generation.

a release preparation PR, which would bump rust package version and cargo.lock, so we can make sure everything is right and working, before creating the release.

@Frigyes06 sure, bumping deps separate from everything else is good, and this can be part of the release checklist document.

As for the second point regarding 'release managers': I think this should be either me or one of the @Universal-Debloater-Alliance/developers; doesn't really matter who of us it is, as long as we know about these guidelines and the process we need to follow.
(@AnonymousWP)

We need to make a final decision on manual vs automated releases. We all said yes to automation in some form, but let me clarify. Regardless of automation, release managers need to do the following basic steps:

• Bump version in Cargo.toml and Cargo.lock
• Commit & push that change; e.g. (git commit Cargo* -m 'release 1.2.3' && git push)

Beyond that, to take advantage of current release.yml automation, they WILL NOT draft & publish a release on the GitHub website.

Instead, they will:

• Create a tag pointing to the commit they just pushed (git tag -s v1.2.3 -am '1.2.3'; -s => sign, -am => annotate with message)
• Push that tag to main directly (git push origin v1.2.3)

Both these steps need to be done via CLI (or perhaps a desktop client as well), as tags cannot be part of a PR. Thus, repository settings will need to be changed to allow only specific members (release managers) to push directly to main.

I am fine with this, because the command for pushing a tag is explicitly different from a normal push, so there's practically 0 chance of someone doing it by mistake. On the other hand, if one were to draft a release on GitHub, it's quite easy to click the more attractive green button by accident:

If others take issue with the idea of pushing directly to main, I understand completely, but then you'd need to come up with an alternate idea for automation.

from universal-android-debloater-next-generation.

sure, bumping deps separate from everything else is good, and this can be part of the release checklist document.

Yep, exactly. I'm thinking how we can make this more visible to the team, so that we do not forget to actually check the checklist document (ha), but we can also just communicate through Discord. I suppose 4 brains are enough to remind each other about the checklist. 😉

We need to make a final decision on manual vs automated releases.

Honestly, even though it's nice to automate, I feel like we'll have to document those commands too then. But does this way of automating also allow us to still edit the changelog in a practical way? For example, previously I had it happen that some changelog lines (coming from PRs) were very bad and inconsistent. I then could easily edit the title of the PR and re-generate the changelog. When you do this automated, you'll have to remove the tag first and then re-push the tag via a commit, I assume?

In that case, I'm probably supporting with hand for the sake of having more control.

from universal-android-debloater-next-generation.

For example, previously I had it happen that some changelog lines (coming from PRs) were very bad and inconsistent. I then could easily edit the title of the PR and re-generate the changelog.

@AnonymousWP You mean with this button? Yes of course you can re-do it however you want.

The release.yml workflow automates two things: building binaries, and creating a latest release with the correct tag & auto-generated changelog. You can do whatever you want with the content of the release after the fact.

from universal-android-debloater-next-generation.

Sure then, but it will likely mean that the changelog won't be perfect, unless I'm including "Check titles of merged PRs to comply with standardization" in the checklist.

Correct me if I'm wrong, but I think we can conclude we're using the automated way. This issue can be closed by a PR I'll create regarding guidelines.

from universal-android-debloater-next-generation.

Closed as per above

from universal-android-debloater-next-generation.