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
