My Page

[#6393] Define API and configuration compatibility process/guidelines.

2012-10-18 12:42
Submitted by:
Markus Schneider (mschneider)
Assigned to:
Markus Schneider (mschneider)
Define API and configuration compatibility process/guidelines.

Detailed description
As a result of discussing [#6389], it has been proposed not to break API/configuration compatibility between minor versions, e.g. between 3.0, 3.1 and 3.2.

Full API compatibility isn't feasible for the 3.x series. We already broke the API a lot of times. However, for 4.0-pre/alpha, this should be considered and requires the definition of a process to ensure it (e.g. clear guidelines, reviews).

Configuration stability has been an important goal for the 3.x series, but this was failed in rare cases, e.g. when the relational mapping concepts evolved. Therefore, PostGISFeatureStore (3.0) and SQLFeatureStore configs (3.1 and 3.2) are not compatible and manual interaction is required, when updating the deegree release for an existing configuration. The TMC still considers config compatibility to be of high importance for the 3.x series, but obviously we must deal with (few) exceptions here. A clear and documented process for configuration stability for both 3.x and 4.x is required as well.


Date: 2013-10-29 14:14
Sender: Torsten Friebe

Accepted by TMC
<tfr42> my vote: +1
<markusschneider> +1
<johanneswilden> same here: +1
<copierrj> +1
Date: 2013-09-30 17:29
Sender: Torsten Friebe

Updated http://wiki.deegree.org/deegreeWiki/deegree3/StabilityManifestoDraft with proposal to use Java 5 annotation @Api for marking the public API of deegree
Date: 2013-03-06 11:20
Sender: Torsten Friebe

Clarification needed also for:
How to use the deegree API. What is stable what is not?
Date: 2012-10-24 13:10
Sender: Markus Schneider

See http://wiki.deegree.org/deegreeWiki/deegree3/StabilityManifestoDraft

Attached Files:


No Changes Have Been Made to This Item

This site is hosted by Intevation GmbH