Development cycle
The Contiki-NG development cycle follows Gitflow.
The master branch contains official releases only.
Development takes place in the develop branch, with all contributions done through pull requests (user-hosted feature branch).
Features are merged when they are deemed useful and fulfill the contribution guidelines (see doc:contributing).
They get consolidated gradually, as more and more developers use them.
Continuous integration guarantees non-regression of develop.
Twice a year – once in the fall and in the spring, a new release is planned.
A tag is added on develop, e.g. for release X.Y, develop/vX.Y, and a new branch release-X.Y is created.
While normal development continues on develop, the release branch undergoes a feature-freeze:
only bug fixes and pre-release polishing are done on release-X.Y. In the long term, all tags prefixed with develop/vX.Y will indicate the point in git history where the release-X.Y branch was created.
Meanwhile, the maintainers carry out more extensive testing of various features on different hardware, check the consistency of documentation and tutorials, etc.
After a 2–4 weeks, when things stabilize, the release branch is merged into master as well as back into develop (so as to include all pre-release work in develop).
The release is tagged on master, e.g. tag release/vX.Y, the release branch deleted, and the release is announced. All release tags will be prefixed by release/
In case a hot fix (i.e. one that avoids a critical fault) is needed between releases, it will be submitted directly to master (either from a user-hosted branch or a dedicated hotfix-xyz branch in the main repo).
When the hot fix is ready, it is merged into master (in turned merged back to develop), and a new minor version is released.
Changelogs are kept at doc:releases.