[FrontPage] [TitleIndex] [WordIndex

deegree stability manifesto (draft)

The overall goal for deegree stability is to achieve the following goals:

1. deegree 3.x

For the deegree 3.x series, the aim is to provide a stable configuration format. The API is explicitly excluded from stability requirements. As stable interfaces come at a price, this decision was made to strike the right balance between stability and still permitting design changes on the evolving code base.

In general, a deegree 3.0 workspace should work without changes in deegree 3.1 or 3.2. However, a few incompatible changes could not be avoided as some design concepts had to be changed that affected the configuration file formats.

1.1. From deegree 3.0 to 3.1

1.1.1. PostGISFeatureStore/SQLFeatureStore

PostGISFeature store configurations (schema) have been replaced by the more generic SQLFeatureStore configurations (schema). Therefore, existing PostGISFeature store configurations need to be manually transformed into SQLFeatureStore configurations. Changes:

1.2. From deegree 3.1 to 3.2

1.2.1. SQLFeatureStore

Some incompatible changes have been applied to the SQLFeatureStore configuration format (old schema/new schema). Therefore, existing SQLFeatureStore store configurations need to be manually adapted.

2. deegree 4.x and beyond

Beginning with the deegree 4.x series, the aim is to provide fully stable configuration formats and API (between minor versions). Any changes in minor versions should be backward compatible, e.g. new configuration options or configuration file types may be added, but existing ones must not be removed.

2.1. Stability ensurance process

In order to achieve stability, a suitable process must be agreed upon:


2018-04-20 12:05