[RFC] Release branches for unity-system-compositor

Daniel van Vugt daniel.van.vugt at canonical.com
Wed Jul 22 01:08:11 UTC 2015


+1

On 21/07/15 18:00, Alexandros Frantzis wrote:
> 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
>



More information about the Mir-devel mailing list