releasesAndContributions

Contributions

We gladly accept contributions. The procedure for this is to make a branch in which you make your changes. In the case of a large change (lots of changes, architectural change, or a new feature), make a proposal. When the change is done, make a Pull Request, and - optionally - contact the mailinglist. All changes must be via separate branches, because we have a separate branch from which we release a stable version. The master branch is protected, so no changes can be automatically be pushed unto master and we have to manually cherry-pick each commit. Each Pull Request must pass the automatic build tests and must be reviewed by a committer, before it can be merged unto master (and later the stable branches).

Branches

There are 2 main branches:

1. master: this is not guaranteed to be stable, but has the most up-to-date features
2. stable: this is guaranteed to be stable, but it's not cutting edge

When making a bugfix, you can port it back to the current stable branch. To do this, make the PR also against the stable branch.

Naming scheme

We release community releases from the master branch.
For a stable release, we make a separate branch. For example, current master is version 5.1.5. To make the stable release: 0. 'Feature freeze' one week before release train: check to see if people are going to add new/untested features in the next week

1. Make branch 5.2.x from master. This will be the base branch for this stable release.
2. Make a release candidate: 5.2.0-rc1. We will test this RC.
3. Fix all found bugs from rc1 and make pull request against 5.2.x and master
4. Merge all PR's against 5.2.x (not master, as these are unconfirmed fixes)
5. Make a second release candidate: 5.2.0-rc2
6. Test this release (everything works now: yay!)
7. Release 5.2.0
8. Merge all PR's against master
9. Make master 5.3.0-SNAPSHOT

Release

Two times per year, B3Partners will release a stable version of flamingo. This release will be thoroughly tested, and only after all tests pass, it will be released. The master/development version - which until now was released almost montly - will be released upon request, or when a developer will feel like it.

It's good to note that new features will only appear in the stable release two times a year.

The procedure for a stable release is:

1. Determine features/bugs to be included in the release
2. Featurefreeze at T - 14 days
3. Testing of release candidate from T - 14 to T - 10
4. Bugfixes from T - 9 to T - 5
5. Test the bugfixes from T - 4 to T -3
6. Last bugfixing
7. Release!

When blocking issues are found after a stable release, a bugfix release will be made against the current stable branch (which will be ported back to master of course). In the example under ''Naming scheme'', this version will be 5.2.1.
There is only one stable branch at any given time.

Version numbers

<MainVersion>.<Minor>.<Sub>

MainVersion: Only increases with very large changes.
Minor: This will be even numbered for stable versions, and odd numbered for development versions.
Sub: Will be increased every subrelease.