OK, thanks for the clarification. I do have a strong opinion. Infra made it clear that rel/ is for tagging releases. Release candidates are NOT releases. Furthermore, if you find a problem before starting a vote it is very easy to just delete a non-rel/ tag and rerun the candidate. Once the vote starts the tag should not be deleted but it is otherwise very confusing to have a vote on rel/1.0-rc1 followed by a vote on rel/1.0-rc3 or rc4. What happened to the missing candidates? It just creates needless permanent tags in the repo and gets annoying for users who are looking for just the “real” release tags.
Release candidates should ALWAYS use a tag that is completely separate from the release tags for the above reasons. To be honest, I might consider voting -1 on future releases that don’t do that. Ralph > On May 4, 2023, at 1:48 PM, Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > > Hi Ralph, > > On Thu, 4 May 2023 at 22:35, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> That makes me question what is in the actual release. Tags named “rel/“ are >> immutable so you can’t have added anything to that after the first rc. > > It took me a while to get the automatic release scripts going. So there was: > > * rel/0.1.0.rc1 (with a dot): first attempt with > `maven-release-plugin`, which pushed the tag, > * rel/0.1.0-rc2: second release candidate, first deployed by Github > Actions, the tag is mine, > * rel/0.1.0-rc1 (as in the vote e-mail): third release candidate, > deployed by Github Actions, the tag was also pushed by GA. In an > effort to order things up I manually pushed `rel/0.1.0-rc3`. > > Sorry for the confusion. I guess the tagging policy will be a hot > topic of the next meeting. Personally I don't have a strong opinion in > this regard, I just copied what `l-l-tools` does. > > Piotr
