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 <[email protected]> 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 <[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] > > > > > -- Sławomir Jaranowski
