Re: [VOTE] Release Maven Release version 3.0.0-M7

[Michael Osipov]

Am 2022-10-29 um 19:36 schrieb Michael Osipov:

Hi,

We solved 7 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317824=12351828

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/projects/MRELEASE/issues

Staging repo:
https://repository.apache.org/content/repositories/maven-1818/
https://repository.apache.org/content/repositories/maven-1818/org/apache/maven/release/maven-release/3.0.0-M7/maven-release-3.0.0-M7-source-release.zip

Source release checksum(s):
maven-release-3.0.0-M7-source-release.zip
e0b1ede39605ea0f5c4d2b05be1fd189e4875b49d285edb1e3f52a0fcce57e46c2b04619a8817275f12d8cf20009e91f349f2c29ff9a4da2aa839813c929acc5

Staging site:
https://maven.apache.org/maven-release-archives/maven-release-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.


+1


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Clarify procedure for restarting releases

[Romain Manni-Bucau]

Hmm, so you mean we should primite not existing releases (for users and
asf) as being actual partial releases?
Not sure which sense it makes from my window when we have all we need to
not create these ambiguitues.
If release process is too heavy we can automate most of it already - we
just never felt the need IIRC, but pushing artifacts manually saves
burnings version numbers which always saves questions and bad time on
consumer sides.
Personally I always favor users to committers but we are free to make our
lifes easier if it is not enough in your opinion, hope it makes sense to
not think to us first.

Le lun. 31 oct. 2022 à 09:37, Michael Osipov  a écrit :

> Am 2022-10-31 um 08:45 schrieb Slawomir Jaranowski:
> > 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.
>
> As said, the version will be closed as archived and you can even add a
> note in JIRA. This should really do it.
> In the past 10 years maybe 10 people asked why there is a tag in Git,
> but nothing on Central. I linked the dev mailing list, done.
>
> Every single additional step will make it even worse.
>
> M
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Clarify procedure for restarting releases

[Michael Osipov]

Am 2022-10-31 um 08:45 schrieb Slawomir Jaranowski:

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.


As said, the version will be closed as archived and you can even add a 
note in JIRA. This should really do it.
In the past 10 years maybe 10 people asked why there is a tag in Git, 
but nothing on Central. I linked the dev mailing list, done.


Every single additional step will make it even worse.

M

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Clarify procedure for restarting releases

[Guillaume Nodet]

Le lun. 31 oct. 2022 à 08:46, Slawomir Jaranowski 
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 
> napisał(a):
>
> > Le lun. 31 oct. 2022 à 07:34, Hervé Boutemy  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 
> > > 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 
> 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

Re: Clarify procedure for restarting releases

[Slawomir Jaranowski]

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.
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 
napisał(a):

> Le lun. 31 oct. 2022 à 07:34, Hervé Boutemy  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 
> > 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  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

Re: Clarify procedure for restarting releases

[Romain Manni-Bucau]

Le lun. 31 oct. 2022 à 07:34, Hervé Boutemy  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
> 
>
> 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 
> 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  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
>
>

Re: Clarify procedure for restarting releases

[Hervé Boutemy]

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  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  a
> > 
> > écrit :
> > > Am 2022-10-30 um 20:32 schrieb Elliotte Rusty Harold:
> > > > On Sun, Oct 30, 2022 at 6:53 PM Michael Osipov 
> > > 
> > > 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

Re: Clarify procedure for restarting releases

[Romain Manni-Bucau]

+1 post-release tagging is the easiest (plus the fact a tag is a hash in
git, not a name ;))

Le dim. 30 oct. 2022 à 21:40, 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  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  a
> > écrit :
> >
> > > Am 2022-10-30 um 20:32 schrieb Elliotte Rusty Harold:
> > > > On Sun, Oct 30, 2022 at 6:53 PM Michael Osipov 
> > > 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
> >
>