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
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 a écrit :
> Hell
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 t
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 fe
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 on
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 l
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 misunderstoo
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 automati
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/
+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 i
+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 clo
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 you
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
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
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. Everythin
On Sun, Oct 30, 2022 at 2:40 PM Elliotte Rusty Harold
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 Jaranow
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
wrote:
>
> Hi,
>
> Current procedure of releases is unclear in case of restart releases. [1]
>
> I see
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.
- dr
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
19 matches
Mail list logo
