You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Slawomir Jaranowski <s....@gmail.com> on 2022/10/30 11:04:03 UTC
Clarify procedure for restarting releases
Hi,
Current procedure of releases is unclear in case of restart releases. [1]
I see two cases:
- technical problem during release ... something goes wrong after SMC tag
was created
- canceled vote
Technically we have many solutions:
1.
- drop old tag and restart with the same version
- no need other actions
2.
- restart process with next version
- don't touch wrong tag in repo
- or drop old tag
- rename release label in jira
- or create next release and add only fixed issues for restart
[1]
https://maven.apache.org/developers/release/maven-project-release-procedure.html#check-the-vote-results
--
Sławomir Jaranowski
Re: Clarify procedure for restarting releases
Posted by Michael Osipov <mi...@apache.org>.
Am 2022-10-30 um 12:04 schrieb Slawomir Jaranowski:
> Hi,
>
> Current procedure of releases is unclear in case of restart releases. [1]
>
> I see two cases:
>
> - technical problem during release ... something goes wrong after SMC tag
> was created
> - canceled vote
>
> Technically we have many solutions:
>
> 1.
> - drop old tag and restart with the same version
> - no need other actions
>
> 2.
> - restart process with next version
>
> - don't touch wrong tag in repo
> - or drop old tag
>
> - rename release label in jira
> - or create next release and add only fixed issues for restart
>
>
> [1]
> https://maven.apache.org/developers/release/maven-project-release-procedure.html#check-the-vote-results
>
Let me describe I have done and likely others for the past 10 years:
Vote has been canceled:
1. Drop staging repo
2. create version n + 1 in JIRA
3. Archive version n in JIRA
4. Assign issues from version n also to version n + 1
5. Don't touch tag in Git repo
6. Fix found issues and assign them to version n + 1
7. start new release process
With this you can:
1. Always trace down the canceled release by source and issues
2. Make clear via ML that release is defunct
Note that versions are cheap and one should rather distinct versions
than having two different source releases under the same tag/name.
Here is an example:
https://issues.apache.org/jira/projects/SCM/versions/12350866
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Clarify procedure for restarting releases
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Oct 30, 2022 at 2:40 PM Elliotte Rusty Harold <el...@ibiblio.org>
wrote:
> 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.
>
Big old +1 on that! :-)
Gary
>
> On Sun, Oct 30, 2022 at 11:05 AM Slawomir Jaranowski
> <s....@gmail.com> wrote:
> >
> > Hi,
> >
> > Current procedure of releases is unclear in case of restart releases. [1]
> >
> > I see two cases:
> >
> > - technical problem during release ... something goes wrong after SMC tag
> > was created
> > - canceled vote
> >
> > Technically we have many solutions:
> >
> > 1.
> > - drop old tag and restart with the same version
> > - no need other actions
> >
> > 2.
> > - restart process with next version
> >
> > - don't touch wrong tag in repo
> > - or drop old tag
> >
> > - rename release label in jira
> > - or create next release and add only fixed issues for restart
> >
> >
> > [1]
> >
> https://maven.apache.org/developers/release/maven-project-release-procedure.html#check-the-vote-results
> >
> > --
> > Sławomir Jaranowski
>
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Clarify procedure for restarting releases
Posted by Slawomir Jaranowski <s....@gmail.com>.
Thanks for feedback.
Reading all of them, I must agree with Michael's proposition - yes it has
been used for many years.
Some of ideas from discussion:
- create tag manually after voting ... not acceptable for me, hope also for
others - we need it only for failed voting ... but we will add more manual
works for all releases
- dropping / moving tag in repository can have impact on fetched local
repositories - and can generate more questions
Users in most cases don't look at repository level.
Versions aren't incremental numbers so it is not important that some of
them will be missing - burned.
I will prepare PR with a proposition for procedure update.
wt., 1 lis 2022 o 18:25 Romain Manni-Bucau <rm...@gmail.com>
napisał(a):
> Leads to the question: what is the most common source for end users.
> Without debate it is not git so burning versions should be on central only
> IMHO. For git we have clean solutions to not burn anything so it sounds
> worth using them IMHO.
>
> Le mar. 1 nov. 2022 à 13:56, Heiko Studt <he...@iteg.at> a écrit :
>
> > Hello,
> >
> > Am 31.10.22 um 08:45 schrieb Slawomir Jaranowski:
> >
> > > We are talking about a situation which happens very rarely - canceling
> a
> > > vote.
> >
> > > In such a case simply delete tag and create next with next release run
> > with
> > > the same label is easy and possible.
> >
> > If your GIT repository has fetched some tag from the remote, it will NOT
> > update this tag later on automatically nowadays. Some clients fetch the
> > tags every 15 minutes, so you will probably have got the wrong tag
> already.
> > After that you will have the wrong version tags in some local repository
> > after the tag was modified on remote.
> >
> > From the "git help fetch"
> > | Since Git version 2.20, fetching to update refs/tags/* works the same
> > | way as when pushing. I.e. any updates will be rejected without + in
> > | the refspec (or --force).
> > (2.20 was released on 2018-12-09)
> >
> > What is the workflow, if one tries to reproduce some issue on a special
> > version? Do you really download the ZIP afresh for each such occasions
> > or do you create a branch in your local repository from that specific
> > version tag and start from there?
> >
> > I understand the reason *against* burning is the question:
> > "why there is a GIT tag but not a release".
> > The reason *for* burning is the question:
> > "why the GIT tag is different to the release."
> >
> > For me, the former is way easier to spot and explain, the latter is
> > error-prone on the user's side if the user is not aware that the tags
> > are to be ignored or explicitely fetched before switching versions.
> >
> > Additionally, the latter may happen for other version artifact as well.
> >
> >
> > MFG
> > --
> > Heiko Studt
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
--
Sławomir Jaranowski
Re: Clarify procedure for restarting releases
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Leads to the question: what is the most common source for end users.
Without debate it is not git so burning versions should be on central only
IMHO. For git we have clean solutions to not burn anything so it sounds
worth using them IMHO.
Le mar. 1 nov. 2022 à 13:56, Heiko Studt <he...@iteg.at> a écrit :
> Hello,
>
> Am 31.10.22 um 08:45 schrieb Slawomir Jaranowski:
>
> > We are talking about a situation which happens very rarely - canceling a
> > vote.
>
> > In such a case simply delete tag and create next with next release run
> with
> > the same label is easy and possible.
>
> If your GIT repository has fetched some tag from the remote, it will NOT
> update this tag later on automatically nowadays. Some clients fetch the
> tags every 15 minutes, so you will probably have got the wrong tag already.
> After that you will have the wrong version tags in some local repository
> after the tag was modified on remote.
>
> From the "git help fetch"
> | Since Git version 2.20, fetching to update refs/tags/* works the same
> | way as when pushing. I.e. any updates will be rejected without + in
> | the refspec (or --force).
> (2.20 was released on 2018-12-09)
>
> What is the workflow, if one tries to reproduce some issue on a special
> version? Do you really download the ZIP afresh for each such occasions
> or do you create a branch in your local repository from that specific
> version tag and start from there?
>
> I understand the reason *against* burning is the question:
> "why there is a GIT tag but not a release".
> The reason *for* burning is the question:
> "why the GIT tag is different to the release."
>
> For me, the former is way easier to spot and explain, the latter is
> error-prone on the user's side if the user is not aware that the tags
> are to be ignored or explicitely fetched before switching versions.
>
> Additionally, the latter may happen for other version artifact as well.
>
>
> MFG
> --
> Heiko Studt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Clarify procedure for restarting releases
Posted by Heiko Studt <he...@iteg.at>.
Hello,
Am 31.10.22 um 08:45 schrieb Slawomir Jaranowski:
> We are talking about a situation which happens very rarely - canceling a
> vote.
> In such a case simply delete tag and create next with next release run with
> the same label is easy and possible.
If your GIT repository has fetched some tag from the remote, it will NOT
update this tag later on automatically nowadays. Some clients fetch the
tags every 15 minutes, so you will probably have got the wrong tag already.
After that you will have the wrong version tags in some local repository
after the tag was modified on remote.
From the "git help fetch"
| Since Git version 2.20, fetching to update refs/tags/* works the same
| way as when pushing. I.e. any updates will be rejected without + in
| the refspec (or --force).
(2.20 was released on 2018-12-09)
What is the workflow, if one tries to reproduce some issue on a special
version? Do you really download the ZIP afresh for each such occasions
or do you create a branch in your local repository from that specific
version tag and start from there?
I understand the reason *against* burning is the question:
"why there is a GIT tag but not a release".
The reason *for* burning is the question:
"why the GIT tag is different to the release."
For me, the former is way easier to spot and explain, the latter is
error-prone on the user's side if the user is not aware that the tags
are to be ignored or explicitely fetched before switching versions.
Additionally, the latter may happen for other version artifact as well.
MFG
--
Heiko Studt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Clarify procedure for restarting releases
Posted by Guillaume Nodet <gn...@apache.org>.
Le lun. 31 oct. 2022 à 08:46, Slawomir Jaranowski <s....@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 <rm...@gmail.com>
> napisał(a):
>
> > Le lun. 31 oct. 2022 à 07:34, Hervé Boutemy <he...@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 <gn...@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 <mi...@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 <
> > > michaelo@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-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > > --
> > > > > ------------------------
> > > > > Guillaume Nodet
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
> --
> Sławomir Jaranowski
>
--
------------------------
Guillaume Nodet
Re: Clarify procedure for restarting releases
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <mi...@apache.org> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Clarify procedure for restarting releases
Posted by Michael Osipov <mi...@apache.org>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Clarify procedure for restarting releases
Posted by Slawomir Jaranowski <s....@gmail.com>.
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 <rm...@gmail.com>
napisał(a):
> Le lun. 31 oct. 2022 à 07:34, Hervé Boutemy <he...@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 <gn...@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 <mi...@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 <
> > michaelo@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-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
--
Sławomir Jaranowski
Re: Clarify procedure for restarting releases
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le lun. 31 oct. 2022 à 07:34, Hervé Boutemy <he...@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 <gn...@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 <mi...@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 <
> michaelo@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-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Clarify procedure for restarting releases
Posted by Hervé Boutemy <he...@free.fr>.
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 <gn...@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 <mi...@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 <mi...@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > --
> > ------------------------
> > Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Clarify procedure for restarting releases
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+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 <ol...@apache.org> 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 <gn...@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 <mi...@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 <mi...@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>
Re: Clarify procedure for restarting releases
Posted by Olivier Lamy <ol...@apache.org>.
+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 <gn...@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 <mi...@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 <mi...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>
Re: Clarify procedure for restarting releases
Posted by Guillaume Nodet <gn...@apache.org>.
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 <mi...@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 <mi...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: Clarify procedure for restarting releases
Posted by Michael Osipov <mi...@apache.org>.
Am 2022-10-30 um 20:32 schrieb Elliotte Rusty Harold:
> On Sun, Oct 30, 2022 at 6:53 PM Michael Osipov <mi...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Clarify procedure for restarting releases
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Sun, Oct 30, 2022 at 6:53 PM Michael Osipov <mi...@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.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Clarify procedure for restarting releases
Posted by Michael Osipov <mi...@apache.org>.
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.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Clarify procedure for restarting releases
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
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.
On Sun, Oct 30, 2022 at 11:05 AM Slawomir Jaranowski
<s....@gmail.com> wrote:
>
> Hi,
>
> Current procedure of releases is unclear in case of restart releases. [1]
>
> I see two cases:
>
> - technical problem during release ... something goes wrong after SMC tag
> was created
> - canceled vote
>
> Technically we have many solutions:
>
> 1.
> - drop old tag and restart with the same version
> - no need other actions
>
> 2.
> - restart process with next version
>
> - don't touch wrong tag in repo
> - or drop old tag
>
> - rename release label in jira
> - or create next release and add only fixed issues for restart
>
>
> [1]
> https://maven.apache.org/developers/release/maven-project-release-procedure.html#check-the-vote-results
>
> --
> Sławomir Jaranowski
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org