Production and development tracks for PharmML

Stuart presented the suggestion of having two tracks of PharmML versions. One “production” (“stable”) track and one “development” track. The production PharmML is intended to be the one supported by tools and libraries and the development version will when ready be (whole or in parts) merged into the development track. The meeting decided that this division should be used and concluded that the current de facto production version is 0.8.1 and the de facto development version is 0.9.

How to reach PharmML 1.0

Three different options for reaching PharmML 1.0 were discussed:

1. Refactor 0.8.1 to keep as much compatibility with current APIs as possible.
   
2. Simply bump the version of 0.9 to 1.0
   
3. Refactor 0.9 Strong arguments were made to not use 0.8.1 as 0.9 has some important bug-fixes and all new features are backwards compatible i.e. should not break APIs.

We decided to use 0.9 as the basis for v1.0 but do refactoring.

Refactoring of 0.9

We discussed some different ideas for refactoring of PharmML 0.9:

1. Refactoring of schema that would not change the actual PharmML content.
2. Refactoring that would remove certain redundancies. For example if the schema allows both SymbRef and Assign the SymbRef could be removed as it is already contained in the Assign. This could greatly simplify the APIs
3. Removing features.

We decided to do both 1 and 2 but not 3 and to monitor the impact of the current code given the proposed changes. Stuart will start this task.

Semantic versioning

We decided to use semantic versioning of PharmML and SO to be clear about the notion of backwards compatibility.

Namespace

We decided to come up with a new namespace naming scheme that does not change with every point release.