Release v1.1.0.post1

[cholmes]

As discussed in #234 - this is a proposed way to handle the changes, that I'm putting up for discussion here.

I made a new branch called v1.1.0-post1 off of the v1.1.0 tag and cherry-picked the commit from #234. I did not update any of the schemas / version numbers.

The idea is once we get approvals (likely aim for at least 4 again) I'd tag this branch as v1.1.0.post1, and then cut an actual release on github, and then publish the release to the website.

I think I would then just delete this branch, after making the tag. main already has the change merged, and has the right dev version numbers. @tschaub - if the 1.0.0.post1 release exists and I just run the publish website job on main will 'the right stuff' happen? Like it'll just grab the latest release text and put it on the website? Will it use the versions from the text, or will it try to use the tag at all?

[tschaub]

v1.1.0.post1 is not a valid Semver version identifier. As mentioned in #234 (comment), we could use "build metadata" to handle corrections to a released version (e.g. v1.1.0+p1).

I'm guessing that the result we want is that https://geoparquet.org/releases/v1.1.0/ is updated with the corrected set of requirements (including the change in #234). I'm also guessing that we'll want the version identifier v1.1.0 to show up everywhere even though we are going to be creating a new tag (e.g. v1.1.0+p1). If this sounds right, it will require some changes to the website to ignore build metadata in tags (but still sort using semver).

[tschaub]

I've opened #236 with changes that I think should work.

[cholmes]

I'm guessing that the result we want is that https://geoparquet.org/releases/v1.1.0/ is updated with the corrected set of requirements (including the change in #234). I'm also guessing that we'll want the version identifier v1.1.0 to show up everywhere even though we are going to be creating a new tag (e.g. v1.1.0+p1).

Yeah, I think that's the proposal. I'm also open to an argument that we should just call it v1.1.1, that it is a change to the requirements (and what a validator should test) even if it's not changing the example files. It doesn't seem awful to me for implementations to be able to read and write a 1.1.0 and 1.1.1 even if they're same, and for 1.1.1 to take a little longer to propogate.

v1.1.0.post1 is not a valid Semver version identifier. As mentioned in #234 (comment), we could use "build metadata" to handle corrections to a released version (e.g. v1.1.0+p1).

Ok, cool. I'll to switch things around to do this after we get a bit more discussion. (wrote that before realizing Tim already did it all).

[cholmes]

Closing this in favor of (superior) #236