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 <[email protected]> a écrit : > Am 2022-10-30 um 20:32 schrieb Elliotte Rusty Harold: > > On Sun, Oct 30, 2022 at 6:53 PM Michael Osipov <[email protected]> > 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: [email protected] > For additional commands, e-mail: [email protected] > > -- ------------------------ Guillaume Nodet
