[RFC] Release branches for unity-system-compositor

[Gerry Boland]

No objection here
-G

On 22/07/15 02:08, Daniel van Vugt wrote:
> +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
> >
>