OGC uses only two digit versioning and overrides the schema files available for one version (e.g. 2.0) if there is a corrigendum to it (e.g. 2.0.1). This is a pity as one cannot "see" which schema/corrigendum version is compiled actually and packaged as Java artifact.
Using semantic versioning, we should reflect such changes to the version of the commons-xml project. However, this includes manual checks triggered by an RSS notification of several ReadMe.txt files and---perhaps sometimes---guessing if the API will break or not. If others have a better solution to this, I'd be very interested!
Anyway, at least the OGC module should be versioned by the datum when the schemas were downloaded to trace the history of the project.
OGC uses only two digit versioning and overrides the schema files available for one version (e.g. 2.0) if there is a corrigendum to it (e.g. 2.0.1). This is a pity as one cannot "see" which schema/corrigendum version is compiled actually and packaged as Java artifact.
Using semantic versioning, we should reflect such changes to the version of the commons-xml project. However, this includes manual checks triggered by an RSS notification of several ReadMe.txt files and---perhaps sometimes---guessing if the API will break or not. If others have a better solution to this, I'd be very interested!
Anyway, at least the OGC module should be versioned by the datum when the schemas were downloaded to trace the history of the project.