Hi, We are talking about a situation which happens very rarely - canceling a vote.
Adding the next manual step like post process tagging only for one reason is not justified. I think that when we have multiple release labels for issues and one will be released and second not, can be misunderstood for final users. Not every user follows the dev list and voting result. In such a case simply delete tag and create next with next release run with the same label is easy and possible. By deleting / moving tag to another commit we don't change git history - all commits are present in history we only change a label for the next commit. pon., 31 paź 2022 o 07:41 Romain Manni-Bucau <rmannibu...@gmail.com> napisał(a): > Le lun. 31 oct. 2022 à 07:34, Hervé Boutemy <herve.bout...@free.fr> a > écrit : > > > if pushing the tag is an additional manual step after the vote, > experience > > shows that it will be forgotten > > > > Well it worked well for multiple projects so I'm sure it can work for > maven. > Dist is another deal and we can also invest automating it IMHO since using > nexus there is no value handling it manually at all next to the standard > maven (build) release procedure. > > > > > > and even if we check its existence in dist-tool and publish what is > > missing, > > people will have to look at the report: > > > > > https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/ > > master/site/dist-tool-check-errors.html > > < > https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-check-errors.html > > > > > > as you can see, the existing manual steps are already not fully followed, > > I > > don't want to be the one who fixes missed steps > > > > Le dimanche 30 octobre 2022, 21:40:00 CET Olivier Lamy a écrit : > > > +1 > > > > > > Exactly if the problem is the tag, we simply don’t push the tag. > > > m-release-p has options for that (don’t push and local clone). > > > The tag is not needed as we are supposed to vote sources tarball. > > > This even make the release process faster as you avoid some extra > network > > > operations such another clone.. > > > If really asking by someone the tag can be pushed in a fork > > > > > > On Mon, 31 Oct 2022 at 6:32 am, Guillaume Nodet <gno...@apache.org> > > wrote: > > > > I don't see the point of burning releases. Imho, this has a negative > > > > impact on users for no benefits. > > > > If the problem is just about not rewriting the git history, we could > > > > simply > > > > tag manually once the vote has succeeded (or find a way to delay > > pushing > > > > the tag even if the tag has been created in your local repo when the > > > > release is built). > > > > > > > > Le dim. 30 oct. 2022 à 20:43, Michael Osipov <micha...@apache.org> a > > > > > > > > écrit : > > > > > Am 2022-10-30 um 20:32 schrieb Elliotte Rusty Harold: > > > > > > On Sun, Oct 30, 2022 at 6:53 PM Michael Osipov < > > micha...@apache.org> > > > > > > > > > > wrote: > > > > > >> Am 2022-10-30 um 19:39 schrieb Elliotte Rusty Harold: > > > > > >>> IMO A failed release should not burn an external facing version > > > > > >>> number. If it does, then the release process is flawed and > needs > > to > > > > > > > > be > > > > > > > > > >>> fixed. > > > > > >> > > > > > >> Why? This I don't understand. From ASF PoV only the source > release > > > > > >> ZIP > > > > > >> file is relevant. Everything else isn't public. The Git tag does > > not > > > > > >> matter actually. > > > > > > > > > > > > If it's not an externally facing version number as used in the > > pom.xml > > > > > > dependency/version element, then it doesn't really matter. I > > thought > > > > > > we were talking about restarting a release requiring a new > version > > > > > > number because the git tag is tied to the version number and the > > git > > > > > > tag can't be deleted or repointed. However if that's not the > case, > > > > > > then I agree it doesn't really matter. > > > > > > > > > > While I have never actively deleted tags, I consider this as > > rewriting > > > > > history what two different source trees appear under the same tag. > > This > > > > > does not sound write. We don't rewrite history and maintain a > linear > > > > > branch strategy whatever is released from master. > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > -- > > > > ------------------------ > > > > Guillaume Nodet > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > -- Sławomir Jaranowski
