[RFC] Release branches for unity-system-compositor
gerry.boland at canonical.com
Wed Jul 22 08:47:15 UTC 2015
No objection here
On 22/07/15 02:08, Daniel van Vugt wrote:
> 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