Release process

As for now, Socon is still as its premise and has not yet reached a stable version (1.0.0). Even if that is true, we will still follow a rigorous release process for each minor release before reaching a stable version.

What do you mean by not stable? When we say not stable it means that some changes between two minors release can have incompatibilities. In short, they are not backwards-compatible. We want Socon to reach the outside world before committing to anything. Maybe we won’t make any changes before the stable version that will break the compatibility, maybe we will.

In any case, Socon is usable. If we deprecate something, you will be notified in the next release note.

Versioning

Socon follows the standard Python versioning scheme. This means that the canonical public version identifiers MUST comply with the following scheme:

[N!]N(.N)*[{a|b|rc}N][.postN][.devN]

Following this scheme, Socon’s release numbering will work as follow:

  • Versions will be numbered in the form A.B or A.B.C. We will ignore the [N!] part, the version epoch, which is only used when project changes the way it handles version numbering in a way that means the normal version ordering rules will give the wrong answer.

  • A.B, is the feature release version number. This will increase every time we add a new feature (1.1 -> 1.2 -> …). When we update the major version, it means that we have made major changes and that we might break backwards-compatibility. Minor version change should be compatible with previous release (Exception for early development that might break backwards-compatibility)

  • C. is only use for bug fixes. 100% backwards-compatibility

  • [{a|b|rc}N][.postN][.devN]. Before a new feature release, we’ll make alpha, beta, and release candidate releases. These are of the form A.B alpha/beta/rc N (1.1a1, 1.1rc1)

Each time we will make a release we will put a tag to indicate the version number and create a release/A.B.x branch where we will integrate bug fixes and apply the final tag.

Release cadence

As previously mentioned, Socon is at its premise. We will try to make a release every month until we reach the stable version around Q2-2023.

Release Cycle

Each release will consists of three parts:

  1. Feature proposal: Discuss on what should be included for the next release.

  2. Development: Develop the feature, make the docs. Try to respect the schedule and deliver all features.

  3. Bug Fixes: When the deadline approaches and we have the features we want, we apply a alpha tag and create a release/A.B.x branch of the master branch. No new features will be accepted during this time.