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 > >
