This is all resolved. I have a 2.5.0 tag now, and the other tags seem to be deleted. ________________________________ From: Steve Lawrence <slawre...@apache.org> Sent: Tuesday, January 14, 2020 10:55 AM To: dev@daffodil.apache.org <dev@daffodil.apache.org> Subject: Re: [DISCUSS] release tag naming scheme
Looks like I forgot to push the 2.5.0 tag. That's one thing I don't like about tags, it's hard to tell if they've been pushed or not. Try fetching tags again. To delete tags from your github fork, run: git push origin --delete $(git tag | grep rel/) Then you'll want to delete your local copies of the tags: git tag --delete $(git tag | grep rel/) On 1/14/20 10:30 AM, Beckerle, Mike wrote: > This step: > > git fetch asf --tags > > didn't work for me. I have no official 2.5.0 release tags in my local sandbox > repo. I do have a 2.5.0-rc1 and 2.5.0-rc2 tag, and the other steps removed > the old tags. > > But I didn't get any new tags for the final 2.5.0. > > In my ad-hoc attempts to see what works, I did a 'git fetch origin --tags', > origin is my personal daffodil fork repo. > > This pulled a bunch of tags, still not the final 2.5.0 tags, but furthermore > I now have all the old rel/vX.Y.Z tags again, so I'll have to clean them. > > How do I get them off my fork so that they won't reappear? > > ...mikeb > ________________________________ > From: Steve Lawrence <slawre...@apache.org> > Sent: Monday, January 6, 2020 2:41 PM > To: dev@daffodil.apache.org <dev@daffodil.apache.org> > Subject: Re: [DISCUSS] release tag naming scheme > > 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. >> > >
