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 <[email protected]> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to