Description
Background
Since we adopted release branches last year where we create our tags corresponding to each release on the commits of the release branch. The version that each of our packages reports on the main (development) branch reports the last tag that appeared in the history of this branch (which could be old, and is likely to not be the last release.). We're using versioneer to manage the version which does this based on the tags it can find. Adding a tag to the main branch corresponding to the start of development of the upcoming release enables us to continue using versioneer and the release branches.
An alterntaive option we considered is merging the release branch back into main, which would achieve a similar result in principle, however in practice if the development branch diverges, we'll end up with merge conflicts and changes that we don't want to merge back in to the development branch.
Description
Release n+1 will be tagged with vYY.MM.dev0 This will be applied to the commit on the main branch where the release branch was created from.
Tasks
- Update Workflows in all repos to ignore dev tags
- Update tag pattern in GitHub Workflows core#311
- Update tag pattern in GitHub Workflows dataloader#143
- Update tag pattern in GitHub Workflows models#1081
- Update tag pattern in GitHub Workflows NVTabular#1812
- Update tag pattern in GitHub Workflows systems#342
- Update tag pattern in GitHub Workflows Transformers4Rec#695
- Update tag pattern in GitHub Workflows #964
- Create
v23.05.dev0tag (pointing at commit where release-23.04 branched from) - Update release branch creation script/process to add empty commit after branch is created
- This ensures that we don't have two tags pointing at the same commit. (Versioneer (git describe --tags) doesn't have well defined behaviour for which tag to return))
- Current release process docs: https://docs.google.com/document/d/12Z8tX94J_TrkGJbSxrOAs-zXqgdTrH5XvXgXEhznTko/edit?usp=sharing