This sounds reasonable, though I wonder how it works with the maven-release-plugin? I thought that automatically created tags.
> On May 5, 2023, at 3:47 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > INFRA has dropped the `rel`-prefixed tag requirement. (See this > `users@infra` thread > <https://lists.apache.org/thread/snkhvbc6vzz58h4r595jy6gbb9hy8rfl>.) > > Yet I get the team's sentiment on provenance and I agree with it. Yet the > RC (release candidates) case is a bit muddy. I propose the following: For > voting purposes, only share the commit ID, and only create a `rel/x.y.z` > tag if the vote passes. > > This captures two conditions stated so far: > 1. Not polluting the tag-space > 2. Immutable references to release commits > > Unless you have objections, I will implement this for `l-l-tools` and > `l-l-transform`. > > ---------- Forwarded message --------- > From: Ralph Goers <ralph.go...@dslextreme.com> > Date: Fri, May 5, 2023 at 6:17 AM > Subject: Re: [VOTE] (RC3) Release Apache Log4j Transformation Tools 0.1.0 > To: <dev@logging.apache.org> > > > 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
