With no objections, I've made the changes. There are no longer any "rel/" tags on github. Run the following to fetch the new tags:
git fetch <remote> --tags Where <remote> is your github.com/apache/incubator-daffodil remote: If everything looks correct, you can delete the old tags on your github fork by running: git push <remote> --delete $(git tag | grep rel/) Where <remote> is your github.com/<userid>/incubator-daffodil fork: Then you can delete your local rel tags by running git tag --delete $(git tag | grep rel/) If anyone notices anything wrong, like a new tag doesn't match an old tag, do not delete your tags and we can always recover them. - Steve 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. >
