gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cutting a gnustep-gui release


From: Richard Frith-Macdonald
Subject: Re: Cutting a gnustep-gui release
Date: Fri, 16 Dec 2016 16:53:47 +0000

> On 15 Dec 2016, at 11:23, Ivan Vučica <address@hidden> wrote:
> 
> On Wed, Dec 14, 2016, 22:47 Riccardo Mottola <address@hidden> wrote:
> Hi,
> 
> Ivan Vučica wrote:
> > Let me know if you would like me to delay or to sync with another release.
> 
> current gui has some important fixes done by fred: they could be
> backported to stable in case?
> 
> Ok, thanks for the response to both yourself and Fred.
> 
> I am not sure what we should backport, we should probably just cut a release 
> and not worry much about a separate "stable" branch. Unless a distribution 
> packager voices interest in us doing so?
> 
> @Richard: Are you interested in cutting a -base release soon?

I have this problem that, when I did the last release I announced that it would 
be the final one of the 1.24.x sequence, and that the next one would be 1.25.0 
breaking binary compatibility ... that was because I wanted to get support for 
the debian multi-arch layout into the code (which means gnustep-make installing 
some things in slightly different places, and gnustep-base looking up resources 
differently at runtime).  Also I wanted to use the 'ng' runtime library 
designation work nicely  for turning on all the latest objc-2+ features, and I 
wanted to allow other binary compatibility breakages that people had waiting.

Due to ill health this year, I have had very little time to do any of that 
stuff, and while I made the basic changes for resource lookup, there has been 
no testing to speak of
On the other hand, this should really only effect non-flattened versions of the 
code (and most people use the flattened filesystem layout) and should not 
change the actual abi (in terms of symbols exposed in the library).  So maybe 
we could do another release in the 1.24.x series if we think the code is still 
binary compatible for practical purposes (ie the way distributions like debian 
currently build it).  I am not certain that it is though.

There are quite a lot of bugfixes in trunk, so perhaps it would be worth doing 
another 1.28.x release ... does anyone know how to use the debian tools for 
checking abi compatibility to see if trunk really is abi compatible with the 
latest release?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]