Updates for the 1.0.0-beta.1 release #161
Conversation
| [OGC Topic 2: Referencing by coordinates abstract specification / ISO-19111:2019](http://docs.opengeospatial.org/as/18-005r4/18-005r4.html). | ||
| Apart from the difference of encodings, the semantics are intended to match | ||
| WKT2:2019, and a CRS in one encoding can generally be represented in the other. | ||
| The CRS MUST be provided in [PROJJSON](https://proj.org/specifications/projjson.html) format, which is a JSON encoding of [WKT2:2019 / ISO-19162:2019](https://docs.opengeospatial.org/is/18-010r7/18-010r7.html), which itself implements the model of [OGC Topic 2: Referencing by coordinates abstract specification / ISO-19111:2019](http://docs.opengeospatial.org/as/18-005r4/18-005r4.html). Apart from the difference of encodings, the semantics are intended to match WKT2:2019, and a CRS in one encoding can generally be represented in the other. |
There was a problem hiding this comment.
This file had a lot of inconsistent hard wrapped lines. I took the liberty of removing the line breaks assuming that we all can enable soft wrapping in our editors. In prose that will be getting multiple updates, I think hard wrapping makes a mess of the diffs.
There was a problem hiding this comment.
How does it make a mess of diff's? I tend to like line breaks because it makes the diff clearer to me - I don't have to look through a full paragraph of stuff for a little change, or to try to understand 10 different changes at once.
I don't feel super strongly if everyone else prefers no line breaks. But I do think if we have line breaks we should. make them consistent, and use like a markdown linter to enforce it.
There was a problem hiding this comment.
If you are only making very small changes, then diffs with hard wrapping can be nice to read. But if you are using hard wrapping, you typically have some line length limit, and when the line length exceeds that, you rewrap all your lines. In this case, making changes that aren't very small result in diffs that are full of noise (due to the rewrapping).
Here are some examples.
A somewhat minor change in text that is initially unwrapped (GitHub highlights the relevant change, I think this is nice): tschaub/line-breaks@unwrapped...soft-change
A somewhat minor change in text that is hard wrapped at 80 columns (lots of noise, who knows what actually changed? I think this is not nice): tschaub/line-breaks@wrapped...hard-change
Both of those changes above are the same change.
There was a problem hiding this comment.
Gotcha. I think maybe github is now better at the soft changes than it used to be. Don't feel strongly, so new way sounds good.
There was a problem hiding this comment.
@cholmes - I discovered that the soft wrapping only applies to "prose" docs (markdown among them). So for non-prose docs (HTML even), it looks like old fashioned hard wrapping is still the way to go.
There was a problem hiding this comment.
Another option is semantic line breaks ;) (https://sembr.org/)
tschaub
force-pushed
the
release-v1.0.0-beta.1
branch
from
41c3bf0
to
4c70ea4
Compare
| @@ -13,7 +12,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S | |||
|
|
|||
| ## Version | |||
|
|
|||
| This is version 0.5.0-dev of the GeoParquet specification. | |||
| This is version 1.0.0-dev of the GeoParquet specification. | |||
There was a problem hiding this comment.
Will this mean that every beta and rc will be 1.0.0-dev? Is there a way to have it be 1.0.0-beta.2-dev?
There was a problem hiding this comment.
We can adopt a different convention, but I think of the -dev modifier as being applied to the next release that we "want" - so typically a minor release instead of a patch release. We could have this be any placeholder really. It could be unreleased even.
| [OGC Topic 2: Referencing by coordinates abstract specification / ISO-19111:2019](http://docs.opengeospatial.org/as/18-005r4/18-005r4.html). | ||
| Apart from the difference of encodings, the semantics are intended to match | ||
| WKT2:2019, and a CRS in one encoding can generally be represented in the other. | ||
| The CRS MUST be provided in [PROJJSON](https://proj.org/specifications/projjson.html) format, which is a JSON encoding of [WKT2:2019 / ISO-19162:2019](https://docs.opengeospatial.org/is/18-010r7/18-010r7.html), which itself implements the model of [OGC Topic 2: Referencing by coordinates abstract specification / ISO-19111:2019](http://docs.opengeospatial.org/as/18-005r4/18-005r4.html). Apart from the difference of encodings, the semantics are intended to match WKT2:2019, and a CRS in one encoding can generally be represented in the other. |
There was a problem hiding this comment.
How does it make a mess of diff's? I tend to like line breaks because it makes the diff clearer to me - I don't have to look through a full paragraph of stuff for a little change, or to try to understand 10 different changes at once.
I don't feel super strongly if everyone else prefers no line breaks. But I do think if we have line breaks we should. make them consistent, and use like a markdown linter to enforce it.
Creating this as part of the release process. I'll tag and release from this branch, then bump the version back to a dev version, and then merge.
I created a page on the wiki for the release process. The v1.0.0-beta.1 release is the result.