Versioning schema

To better control the releases and dependencies of our software as also our documentation, we need to adopt a versioning schema. The schema choosen is the Semantic Versioning 2.0.

The Semantic Versioning follows the following structure: MAJOR.MINOR.PATCH

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

Since our modules are separated packages, every module must follow their own version. The core project defines the global version of our integrated system.

With this schema, we can have diferent version for each module, where we can define any dependencies between them, without having to worry on updating modules version imcompatible with each other.

Because we cannot have 2 different versions at the same time, some problems may arise, like having a Module that depends on 2 modules on a specific version, and one of those 2 modules depends on the other but on a diferent version of the first.

Something like that can never happen, and this kind of problems must be discussed by the team.

The solution to this, is to upgrade the Process Managment so that it can work with the most latest version of the Document Management module used by the Plan Management or upgrade both modules to the latest version of the Document Management

Release plan

Features to include on the next release must be defined as early as possible. New features may be included during development, as long as they are agreed by the team and costumer (if any).

A release number may be proposed, but it can change until the new release is released.

When to release a new version

A new version is released when the team agrees that the software has all the features ready, according to the release plan. The release number is freezed just before the release.