if pushing the tag is an additional manual step after the vote, experience shows that it will be forgotten
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 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
