+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.
