Release tags

[TomekTrzeciak]

https://github.com/pydata/xarray/releases marks v0.11.2 as the latest release, rather than v0.12.1. Is this intended?

[max-sixty]

Good spot @TomekTrzeciak

That's not intended. 0.12.1 is at least tagged. Anyone know why GH doesn't treat it as a release?

[TomekTrzeciak]

@max-sixty, you can see 0.12.1 under releases section by clicking 'show newer tags', but 0.11.2 is still marked as the latest. I suspect it's down to annotated vs. lightweight tags and how github interprets them. It seems like annotated tags are preferred for releases.

[dcherian]

It appears that you can mark a tag as "release" on this page: https://github.com/pydata/xarray/tags . Since we missed a few tags, I don't know if we should move directly to 0.12.1 or mark the intermediate tags as releases too.

[max-sixty]

I'll do it for 0.12.1 so at least the latest is correct - any objections? (will do it this eve EST)

[max-sixty]

I think we need to ensure we do this step in future: https://github.com/pydata/xarray/blob/master/HOW_TO_RELEASE#L40

Closing the issue for now; thanks posting it @TomekTrzeciak

[max-sixty]

FYI I just did this for 0.12.3, which didn't show a 'release' on GH

[shoyer]

Hmm.. I wonder if we can just tell GitHub somehow to automatically treat tags as releases. It's a little annoying to have to do it separately.

[max-sixty]

I do wince a bit reading the full checklist - could we write a script to do most of this? I'm happy to help.

Are there any projects that do this well? e.g. a script with release_script.py --version=0.12.4

Someone mentioned Hypothesis, which releases on every merge to master - though I wonder whether it makes merging to master more 'expensive'.