Le lun. 31 oct. 2022 à 08:46, Slawomir Jaranowski <s.jaranow...@gmail.com> a écrit :
> 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. > Is it really ? I haven't been able to do it for 4.0.0-alpha-1. Maybe that's just a role permission problem, but when I tried to delete the tag so that I could cut another release, that was rejected. > 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 > -- ------------------------ Guillaume Nodet
