Yes, the maven release plugin creates tags (unless you configure it to create a branch instead). But Volkan is not using the release plugin.
I am not really sure what the issue is with creating a tag named log4j-tools-1.1.0-rc1. These tags can be deleted later if you don’t want them once the rel tag is created. Yes, one can work from the commit id but that is a bit cumbersome. Ralph > On May 5, 2023, at 9:11 AM, Matt Sicker <m...@musigma.org> wrote: > > 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 >
