Re: GNUstep releases this month?

[Ivan Vučica]

(This is not a release announcement)

A signed build of gnustep-gui / gnustep-back 0.29.0 has been uploaded
at http://badc0de.net/gs/2021.

Actual final releases will, as always, be distributed via GNUstep FTP.
Please give this test build a go.

===

Psst! If you are using themes such as Rik, you might need to rebuild
them, even if there were no code changes. This is usually the case, I
suspect, as well; but today I was bit by it for the first time. It was
curious as I only saw problems on applications I rebuilt -- which in
retrospect makes sense, given the SO bump.

===

Now that all four libs are prepared, I will give it a few days to
receive a stop signal, or an actively-green-light from maintainers.
Then I will send out announcement emails, create GitHub releases, etc.

Of course, if you spot a small thing that we _can_ fix post release
(i.e. not a full showstopper), I will be happy to cut a smaller
point-release.


On Mon, Apr 26, 2021 at 10:34 PM Ivan Vučica <ivan@vucica.net> wrote:
>
> (This is not a release announcement)
>
> A signed build of gnustep-base 1.28.0 has been uploaded at
> http://badc0de.net/gs/2021.
>
> Actual final releases will, as always, be distributed via GNUstep FTP.
> Please give this test build a go.
>
> I will continue preparing gnustep-gui and gnustep-back.
>
> On Thu, Apr 22, 2021 at 8:12 PM Ivan Vučica <ivan@vucica.net> wrote:
> >
> > I am resuming work on releases today and hope to prepare at least
> > -base tarball today.
> >
> > On Fri, Mar 26, 2021 at 11:43 AM Frederik Seiffert
> > <frederik@algoriddim.com> wrote:
> > >
> > >
> > > Am 22.03.2021 um 19:03 schrieb Richard Frith-Macdonald 
> > > <richard@frithmacdonald.me.uk>:
> > >
> > > IIRC the standard/historic behavior is that an object can retain itself 
> > > in the -dealloc method, to extend its own lifetime, and I guess that the 
> > > singletons do that (I haven't checked).
> > > I think that behavior changed for ARC, so it could be that the runtime is 
> > > performing an ARC style deallocation when it should be calling 
> > > NSDeallocateObject() (or something odd is going on in the 
> > > NSDeallocateObject() function).
> > >
> > >
> > > I’ve pushed a change in the following PR that fixes the test failure:
> > > https://github.com/gnustep/libs-base/pull/177/commits/e1e661286a6b9d717dc0312bed5f8b4b5e549d6f
> > >
> > > Frederik
> > >