Hi all,
in the Mir project we are following the standard practice of forking off
a new branch from trunk for each (minor) release. The benefits of this
approach are well known, but to summarize, the main points are:
* Decouples trunk from the release process, i.e., we don't need
to temporarily freeze trunk to release from it.
* Allows us to handle multiple versions more cleanly and effectively
(e.g., fix a bug in a particular released version).
For the reasons mentioned above, I propose that we move to the same
scheme for unity-system-compositor too. At the moment,
unity-system-compositor does not follow this model, instead having a
trunk and single packaging/release branch, tracking the latest released
version.
We can select any version scheme that suits us, but one recommendation
is that we bump the main version number (whichever we decide that to
be), and therefore create a new version branch, at least every time USC
is changed to use a newer server or client API/ABI.
In other words, if we use the minor version as the main version, we want
to guarantee that all releases 0.x.y will continue to work with the same
mir library ABIs that 0.x.0 was originally released against. This scheme
makes it straightforward to manage updates/fixes for released versions
as point releases.
Thanks,
Alexandros
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
