chore: associate a commit with beta release #5530
Conversation
Signed-off-by: Aman Sharma <mannu.poski10@gmail.com>
|
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. |
| 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.
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.
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.