Skip to content
This repository has been archived by the owner on Oct 23, 2024. It is now read-only.

releasesAndContributions

Jump to bottom
Meine Toonen edited this page Feb 6, 2018 · 11 revisions

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

Feature- and bugfixbranches must not be removed after merging into master. Only after being merged into stable, a feature- of bugfixbranche can be removed.

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:

  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

One month after the stable release, a community release is done, and master will now be on version 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.

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.

Clone this wiki locally