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 > > >
-- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
