emscripten-core / emscripten-core/emscripten

Release tagging process conventions have changed?

Open
#14,929 6 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
27.6k
Forks
3.6k
Avg merge
1d 1h
Merged PRs (30d)
105

Description

Since the start of the project, up until Emscripten 2.0.19 release ( #14087 ), we have followed a release tagging convention where:

1) new changes in trunk are accumulated under a ["Current Trunk" section in ChangeLog.md](https://github.com/emscripten-core/emscripten/commit/975d6edec33b23b9f507966c3e84b90260ef0abc#diff-874f33563125619a7a5cb567ebe523c59258662d69858d78d24d947b275f9c6cR21).
2) the commit that bumps the version tag, e.g. [2.0.19](https://github.com/emscripten-core/emscripten/pull/14087/commits/53d7c1268fa27b8980120db54a9b5b49eba3f323) also receives the identically named git tag `2.0.19`.
3) the files emscripten-version.txt and ChangeLog.md are updated in the very same commit that updates the version and is tagged.

This process has worked well to my understanding, without complaints(?), though maybe I missed some conversations while I have been away.

This process has had the effect that when one git clones a git branch and looks into `emscripten-version.txt`, when it reads `2.0.19`, it should be read as "version 2.0.19 (that has already been released before) + then some commits that will become a part of next tag 2.0.20".

Starting from #14110 and #14115, we seem to have lost this procedure:

1) when one reads `2.0.20` in emscripten-version.txt, I presume it now means "this is not actually yet version 2.0.20, but will become it"?
2) when the emscripten-version.txt file is bumped in a commit, that commit no longer gets a tag that corresponds to this update.
3) the tags seem to now correspond with arbitrary points in time instead of the commit that actually did the bump. Why is that specific commit tagged as that version? The tag point looks somewhat arbitrary for this version:

![image](https://user-images.githubusercontent.com/225351/130454544-576849f4-3b5f-4d75-8c9b-f37b6d672c3e.png)

Commits *both* before and after tag 2.0.27 have emscripten-version.txt read `2.0.27`. That seems wrong?

4) reading the changelog at any given snapshot now gives false information about a release. E.g. if I take a snapshot at `a3b27c41d5f1caf617fc8a0f9cd84412fed1b0ab`, I get this ChangeLog for 2.0.26:

https://raw.githubusercontent.com/emscripten-core/emscripten/a3b27c41d5f1caf617fc8a0f9cd84412fed1b0ab/ChangeLog.md

whereas instead if I take a snapshot at `c515787ea5ee0a9b1f65b10c32b427ccb573e74c`, I get this ChangeLog for 2.0.26: https://raw.githubusercontent.com/emscripten-core/emscripten/c515787ea5ee0a9b1f65b10c32b427ccb573e74c/ChangeLog.md

Both of those ChangeLogs read like the "final" or "official" changelog for 2.0.26, without giving a clue that neither of them are actually the complete version 2.0.26.

Would it be possible to revert to the old convention where the ChangeLog would read "Current Trunk" for unreleased changes to not cause confusion, and that the git repo tag+ChangeLog+emscripten-version.txt are consistently and coherently updated in a single coordinated commit like it used to be?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.