chore: associate a commit with beta release #5530
Conversation
Signed-off-by: Aman Sharma <[email protected]>
|
Hey, From my perspective, the beta releases are only a relict of the past, and I am against promoting them as real releases. Beta releases are a random snapshot of the master, and we have no ability to express what this release contains. Our SemVer releases are way better for end user and should be the preferred usage. Since our CD upgrade we do them more often (we should still push more fix releases, but that's another topic). I would prefer to stop releasing them before we add many commits to the master for beta releases. |
|
I understand your point. I think the beta releases exist because our main release cycles were slow to incorporate a features/fixes on the |
|
So should I close this PR and submit a PR for removing/disabling beta releases? The goal is that all packages that are pushed to maven central should be reproducible. |
|
I discussed this topic with @monperrus. We decided to fully commit to beta releases. Every beta release should get a tag and a commit on master. Sorry for the confusion. |
|
@I-Al-Istannen if you are also in favour of " Every beta release should get a tag and a commit on master", should I submit a PR to merge the two release processes? I would change https://github.com/INRIA/spoon/blob/master/.github/workflows/release-beta.yml#L11 to use |
|
I am not quite how you would merge them, as they use a different naming scheme (but both deploy to maven central, and not sonatype snapshots, right?). Committing the |
Yes. This is why I thought I could merge them. However naming scheme, commit message, and tags would differ like you said. Thanks for pointing it out. Then I believe reviewing this PR itself would be better. |
|
Hi! Can we merge this? We want to do it for the sake of reproducibility checks on our beta releases. |
chore/release-beta.sh
Outdated
| echo "::group::Updating poms to next target version" | ||
| mvn -f spoon-pom --no-transfer-progress --batch-mode versions:set -DnewVersion="$NEXT_RELEASE_VERSION" -DprocessAllModules | ||
| mvn --no-transfer-progress --batch-mode versions:set -DnewVersion="$NEXT_RELEASE_VERSION" -DprocessAllModules | ||
| mvn -f spoon-javadoc --no-transfer-progress --batch-mode versions:set -DnewVersion="$NEXT_RELEASE_VERSION" -DprocessAllModules | ||
| echo "::endgroup::" |
There was a problem hiding this comment.
As far as I can see you do not actually update anything as NEXT_RELEASE_VERSION is already identical to whatever was there originally?
There was a problem hiding this comment.
Ah wait, it was changed in between, the messages and names are just confusing. Maybe just drop NEXT_RELEASE_VERSION and rename CURRENT_VERSION to ORIGINAL_VERSION and then use that variable here. And update the messages to say that you are reverting to the old version and not the next target.
There was a problem hiding this comment.
NEXT_VERSION is the beta version for which the commit needs to be pushed. So I push the commit, after rewritting POMs, in R30-R42.
Next is NEXT_RELEASE_VERSION which is the SNAPSHOT. It will be the same version before the beta version as we don't have SNAPSHOT versions for beta as well. The name of this variable is confusing, a better name would be SNAPSHOT_VERSION_TO_RESET_TO.
P.S. Sorry I did not notice your reviews earlier.
|
@algomaster99 Could you change the names? :) |
|
@I-Al-Istannen I am sorry. Completely lost context, but I changed what you asked. |
chore/release-beta.sh
Outdated
| echo "::group::Updating poms to next target version" | ||
| mvn -f spoon-pom --no-transfer-progress --batch-mode versions:set -DnewVersion="$NEXT_RELEASE_VERSION" -DprocessAllModules | ||
| mvn --no-transfer-progress --batch-mode versions:set -DnewVersion="$NEXT_RELEASE_VERSION" -DprocessAllModules | ||
| mvn -f spoon-javadoc --no-transfer-progress --batch-mode versions:set -DnewVersion="$NEXT_RELEASE_VERSION" -DprocessAllModules | ||
| echo "::endgroup::" |
There was a problem hiding this comment.
Ah wait, it was changed in between, the messages and names are just confusing. Maybe just drop NEXT_RELEASE_VERSION and rename CURRENT_VERSION to ORIGINAL_VERSION and then use that variable here. And update the messages to say that you are reverting to the old version and not the next target.
|
@I-Al-Istannen done! |
|
@I-Al-Istannen let's merge? |
|
Actually, sorry: Could you maybe just revert the commit (with a custom message ideally) and then push that? Instead of invoking all kinds of maven stuff that might fail somehow? |
|
If that's annoying, I am also fine enough with this solution |
I don't understand what you mean. Revert which commit? |
|
The commit made by the workflow, bumping the version for the release |
|
Good idea. Can do that. |
|
@I-Al-Istannen done! I removed maven stuff and I also added a command at the end to delete the remote branch from repository. |
|
Then let's see what breaks... :^) |
|
Hoping my Sunday is not ruined 🤞 |
|
Nothing broke it seems :D |
|
@I-Al-Istannen should we mark the release as pre-release instead of latest? |
I am proposing changes in the beta release script to associate commit with a release so that the reproducibility of all releases on maven central can be checked by reproducible central. They are not able to do so right now because they cannot find the source code corresponding to the release.
I simply just copied the content from
release.shtorelease-beta.shto push the commits. However, I am not sure howjreleaserwill know which commit to tag as it is on a different branch, but I assume it would work as it works for normal releases.