Maintaining Reverse Compatibility

Right now, OGC's Architecture Board (OAB) is trying to create guidance for describing and maintaining reverse compatibility. The following are my recommendations based on my experience with GeoPackage.

0. (Prime Directive) Do no harm. Practicality should be the most important consideration. Understand what existing implementations are doing so that you do not cause them new problems with the changes. However, do not shackle yourself unnecessarily. With new standards it is not unusual for obscure parts of the standard to be unused operationally. If they are wrong, fix them while you still have a chance.

1. The semantics of existing elements shall not be changed if they are in use operationally. In https://github.com/opengeospatial/geopackage/issues/137 we did not permit ourselves to change the way the WKT was encoded. Instead we created a new extension which adds a column.

2. New requirements may be added for any reason as long as doing so does not adversely impact interoperability. In https://github.com/opengeospatial/geopackage/issues/102 we knew we had an interoperability problem. The new requirement corrects that problem but there is nothing we can do about implementers that misinterpreted the (admittedly ambiguous) original text.

3. Existing requirements shall not be changed, relaxed, or removed if existing implementations rely on them being met. In https://github.com/opengeospatial/geopackage/issues/130 we had a consistency problem that we were able to correct because while existing implemetations were creating the rogue columns, they were not reading or writing to them. In https://github.com/opengeospatial/geopackage/issues/147 we moved a requirement from core to an extension because it wasn't being used operationally and it was just an annoyance for implementers.