I think the best we can do is send out an email to this list, and perhaps the user list, when the tags are updated and include the commands to delete the old tags. Most likely the people that care about tags are on one of these lists.
And if they never prune tags, it's still not too big of deal. The old tags still point to the same commits and it's completely unambiguous that "rel/vX.Y.Z" and "vX.Y.Z" are the same, so there shouldn't be any confusion. The only thing that is some what important is that Daffodil committers prune tags so that they don't accidentally push old tags. And all committers are definitely on this list so they'll get the notice. And even then we can just redelete the tags if they get accidentally pushed. On 1/3/20 2:25 PM, Kilo, Olabusayo wrote: > +1 > > I think the initial work of getting it be where it needs to be is worth it. > And it doesn't require much of the users. I wonder how will we let customers > know how to 'refresh' their tags? > > On 1/3/20 11:59 AM, Steve Lawrence wrote: > > Since we're nearing another release, I thought it might be worth brining > up something that's been a minor annoyance to me, and see what others think. > > Our currently release workflow is that we add tags for release > candidates of the form "vX.Y.Z-rcN" and then when we make a final > release, that tag becomes "rel/vX.Y.Z". So final releases get a "rel/" > prefix. > > I'm not really sure where this came from, but it seems pretty > non-standard, and makes it somewhat difficult to determine what the > latest release is by looking at tags. For example, the current "git tag" > output (truncated a bit) is this: > > rel/v0.1.0 > rel/v0.2.0 > rel/v0.3.0 > ... > rel/v2.2.0 > rel/v2.3.0 > rel/v2.4.0 > v0.10.1-rc1 > v0.11.0-rc1 > v0.12.0-rc1 > ... > v2.4.0-rc1 > v2.5.0-rc1 > v2.5.0-rc2 > > Notice that the latest release is 2.4.0, which is somewhere in the > middle of this fairly large list. git tag doesn't now how to sort this > properly, so you need to do something like "git tag | grep rel" to find > it. This isn't standard and so most people probably won't recognize to > do this grep. > > But if we drop the "rel/" prefix for releases, git tag will sort this as > you might expect, and you get something like this: > > v0.1.0 > ... > v1.0.0-rc1 > v1.0.0-rc2 > v1.0.0 > v1.1.0-rc1 > v1.1.0-rc2 > v1.1.0-rc3 > v1.1.0 > ... > v2.2.0-rc1 > v2.2.0-rc2 > v2.2.0 > v2.3.0-rc1 > v2.3.0 > v2.4.0-rc1 > v2.4.0 > v2.5.0-rc1 > v2.5.0-rc2 > > Notice that the rc's always come before the final tag, making it much > easier to see what the most recent final tag is, and if there are any > newer development tags just by looking at the last few rows of the > output. For example, we can see the latest final release is 2.4.0 and > there have been two 2.5.0 release candidates. And 2.5.0 hasn't bee > release yet. > > So, I suggest that we rename all the release tags to remove the "rel/" > prefix and we create all future tags without this prefix. Not only does > this make the 'git tag' output easier, but it also follows standard tag > naming conventions. > > One drawback here is that git doesn't really have a concept of tag > renames. Instead, we need to delete the old tags and add the new. Tag > deletion is usually to be avoided, and existing clones will still have > the old tags unless they explicitly remove them, but there's no harm in > having the old tags locally. > > Additionally, because tags are not automatically deleted on a fetch, it > is pretty straightforward to verify that the new tags match the old > tags. Once the tags are pushed, we just need to do a 'git fetch origin > --tags' to fetch the new tags. Then we can inspect that every new > release tag matches an old release tag. Then the user can delete the old > tags, e.g. "git tag --delete `git tag | grep 'rel/'`". > > Thoughts? > > > -- > Best Regards > Lola K. > > Lola K. >
