+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 <[email protected]> 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 <[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 >
