Maintaining legacy branches (aka the 1.1.n vs. 2.x shootout)
The epsos project has decided to split itself into epsos1 and epsos2, which are not compatible in their technical implementations. OpenNCP plans to develop the epsos2 services, while still have maintenance versions of the epsos1 services.
In git, the solution will be to have the 2.x development in the develop branch, and the 1.x legacy version in a maintenance branch.
When 1.1.1 is released, the git-flow model dictates that the release branch is closed, and merged into master and then develop. The next release (1.1.2) would then branch off develop and continue as a (temporary) release branch. However, then 2.x work has already been committed to the develop branch, so we need to create a legacy branch off either the 1.1.1 release branch, or the master branch just after the 1.1.1 release branch has merged into that.
This will result in the git repositories having a 1.1 maintenance branch and the normal master, develop and release and feature (not show in diagram) branches:
Version numbers in the individual components of OpenNCP
Even though OpenNCP has fairly even releases under a common version numbering system, as also described above, the individual components follow their own versioning scheme, independently of the OpenNCP releases. This poses a problem when it comes to splitting the current development effort into two branches. The proposed solution is to apply a bump in the major version for all components in the develop
branch. The legacy branch will continue with the current versions, but will never have a major bump. The applicable version numbers will be updated on the Version Management page