Release tags point to non-existing commits in github

[kgabor]

It seems that the version tags created by release-version.sh tag a local commit that is never pushed to github (beside the downloadable zip?). Therefore the tags cannot be easily associated to any point in the github repository code history.
GitHub says:

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

I'd propose that either the release commit could be pushed to master or to a "release branch" explicitly or, alternatively, the Bump to next development cycle commit could be improved to Released x.y.z. Bump to next development cycle and putting the tag x.y.z. to point here.

[ctrueden]

@kgabor It was an intentional choice years ago to push the release commit to an orphaned tag, rather than having it appear in the mainline history. It certainly is pushed to GitHub, or else you would not be able to check out the commit.

I have considered changing the release-version.sh script to no longer do that, but I haven't had any compelling reason to change it, other than the fact that the current behavior is confusing. A reason not to change it would be that we'd then have a "mixed history" with recent releases on the mainline branch, and past releases not, which is arguably even more confusing than the status quo.

Is there something in particular you are not able to do, which you would be able to do if we left the release commits as part of the mainline branch history?

[kgabor]

@ctrueden I just noticed that my git client (gitqlient) program does not jump to anywhere in the history when I click the release tags to see when/where they happened in terms of branch merges/features. (I wanted to look up the Fiji versions of multiview-reconstruction in the repo.) I just expected that tags actually tag a point in the repository.

Lacking the tags, I think it'd be nice to say "Released x.y.z. Bump to next..." in the "Bump" commit messages.

If we don't want to do a release commit (with the released version number in the pom) then change the version again in the next commit ("Bump..."; with the "SNAPSHOT" in the pom.) on master why don't we leave the release connected on a one commit branch with the tag? I think numpy uses this approach, which also makes it possible to backport features/bug fixes to an existing release if there is capacity/demand for that.

Thanks!

[ctrueden]

just noticed that my git client (gitqlient) program does not jump to anywhere in the history when I click the release tags to see when/where they happened in terms of branch merges/features.

Does it help if you git fetch --tags first? I would expect that command to explicitly fetch all the tagged commits, such that git clients can orient themselves correctly in the history with them. Certainly the tags do point to actual commits within the repository... just not ones on any branch.

also makes it possible to backport features/bug fixes to an existing release if there is capacity/demand for that.

In Maven terms, releases are immutable. That is: you can push a bug-fix for 3.5.4 as a new release 3.5.5, but you cannot modify the existing 3.5.4 release.

I think I would prefer to simply change release-version.sh to stop doing orphaned tags, in favor of keeping the release commits on the mainline branch.

The diff is probably:

diff --git a/release-version.sh b/release-version.sh
index b0eb696..42cdbf7 100755
--- a/release-version.sh
+++ b/release-version.sh
@@ -341,20 +341,6 @@ $DRY_RUN mvn $BATCH_MODE release:prepare -DpushChanges=false -Dresume=false $TAG
        die 'The release preparation step failed -- look above for errors and fix them.
 Use "mvn javadoc:javadoc | grep error" to check for javadoc syntax errors.'
 
-# Squash the maven-release-plugin's two commits into one.
-if test -z "$DRY_RUN"
-then
-       debug "Squashing release commits"
-       test "[maven-release-plugin] prepare for next development iteration" = \
-               "$(git show -s --format=%s HEAD)" ||
-               die "maven-release-plugin's commits are unexpectedly missing!"
-fi
-$DRY_RUN git reset --soft HEAD^^ &&
-if ! git diff-index --cached --quiet --ignore-submodules HEAD --
-then
-       $DRY_RUN git commit -s -m "Bump to next development cycle"
-fi &&
-
 # Extract the name of the new tag.
 debug "Extracting new tag name"
 if test -z "$DRY_RUN"

I.e. just removing the "Squash the maven-release-plugin's two commits into one" part. I will test this the next time I cut a release, and if all is well, push the change. For existing components it will result in a mixed git history, but I'm OK with that. Better now than later.

[ctrueden]

@kgabor I tried releasing a new version of scijava-common with the changed release-version.sh that no longer squashes the two commits into one on the main branch. But it didn't work as desired: I still ended up with an orphaned commit for the tag, and another release commit on the main branch purporting also to be the release commit:

* 3f056acb (HEAD -> master, origin/master, origin/HEAD) [maven-release-plugin] prepare for next development >
* 7e42b24a [maven-release-plugin] prepare release scijava-common-2.97.0
| * 35b5935a (tag: scijava-common-2.97.0) [maven-release-plugin] prepare release scijava-common-2.97.0
|/
*   664b3ab4 Merge branch 'enum-choices'

And this caused problems also with the CI pipeline.

See also this thread on Zulip.

@kgabor I don't have time to mess with this any further, and you haven't responded to my questions above (e.g. about whether git fetch --tags helps), so I'm going to close as "not planned" due to the high chance of downstream breakages caused by a change like this. The current release process works just fine, and having an orphaned release commit does not really cause problems other than occasional confusion when git clients don't deal with it nicely.