Update Requirement 2 to account for version increments

[jyutzler]

Right now requirement 2 specifies an exact string for the version but the spec is supposed to be reverse compatible so that, for example, a version 1.2 GeoPackage operates as designed on a 1.0.1-based client. Strict adherence to this requirement makes this impossible. We need to rewrite the requirement so that it accounts for version increments.

[bosborn]

This is good in theory but there have been some fairly significant changes along the way. I support handling previous versions as much as possible, but some changes are not worth the code maintenance. Would like to avoid an overly complex implementation to handle previous versions of an early adopted specification.

The optional definition_12_063 column (previously definition_12_163) of the gpkg_spatial_ref_sys table is a good example. A GeoPackage SQL implementation abstraction (such as ORM) must handle when this column does and does not exist. While not overly difficult, it is not trivial and adds to the implementation complexity.

Was version 1.2 officially released on 2016-09-28 as indicated by the current specification or is it still in the works? See pull #252 to bump the version number.

[jyutzler]

What we need is for things not to hard-fail when the version number doesn't match exactly. We do not expect implementers to support all previous versions (it kind of defeats the purpose of spec maintenance) but we want to allow an organization to choose to do so (for example, implement everything in 1.2 but still be able to pass a 1.0.1 compliance test. I have not proposed a specific change yet - I want to get more feedback on what would be an improvement or if this is even needed.

1.2 is not adopted yet but we are nearing the end of what might be considered a beta period. When I am all the way done preparing the release (including release notes and change log), it will be submitted to OGC so that a 30-day review can be started. I hope to complete all of this by New Year's.

[jyutzler]

GeoPackage is an encoding standard. In other words, it does not impose requirements on clients, merely describes what is allowed in a GeoPackage and what everything means. The way to deal with this issue is to note in prose (outside of a requirement statement) that new versions of GeoPackage are possible and that an application should not fail if it does not see an exact string (e.g., GP11) in that place.

We need to update the abstract test /base/core/container/data/file_format/application_id as well.

Meanwhile we have already been talking to the people responsible for the CITE tests to make sure that those tests don't fail when they see an unexpected value there.