Re: Package releases at homepage

[Adrian Robert]

On Jan 31, 2005, at 2:32 AM, stefan@agentfarms.net wrote:

> Citát Adam Fedor <fedor@doc.com>:
>
> > On Jan 30, 2005, at 10:06 AM, Adrian Robert wrote:
> >
> > > > My suggestion is to put there references to packages:
> > >
> > > > GNUstep-core-x.x.x | Release Info
> > >
> > > This is a fantastic idea.  The core package can still keep
> > > base,gui,back subdirectories, and the "compile-all" script
> > > already there actually does installation too.  The INSTALL
> > > file suggests installing things individually, but this is
> > > probably not so relevant except for developers, and they
> > > will presumably be using CVS checkout anyway.
> >
> > Several problems.
> >
> > 1) The libraries are released on different schedules.
>
> No problem. As I have mentioned: each library release bumps minor 
> version number
> of the core package. Say we start with GNUstep Core 1.0.0. Then we 
> release
> GNUstep Core 1.1.0 when we release base 1.11.0. It is like you 
> increase -base
> version number when you modify/add several functions there - only 
> there is a
> shift to higher layer: methods/classes/functions -> subproject. 
> GNUstep core is
> meta-package and its components are gnustep sub-projects. Change of 
> subproject
> results in change of the meta package.

Yes, the meta package gets a new release whenever any of its components 
does.  Part of its release process is a compilation and test suite 
test, ensuring at least basic compatibility among the new combination 
of component releases.  This wouldn't be much more work if any, since I 
assume this testing is being done already when either make/base or 
gui/back is released.


> > 2) Compiling everything together works great IF everything goes well,
> > but the huge variety of platforms means something goes wrong at some
> > point. Then we get a bug report like:
> >
> > include file "AppKit/NSApplication.h" missing
> >
> > when the real error was probably installing a previous library.

I'm not sure what you mean here.  It would seem if the user is 
installing only 'core' packages with compatible make/base/gui/back tied 
together in lock-step, it would reduce the chances of such errors vs. 
them upgrading base or gui willy-nilly (depending on when things get 
released on the web site, when they happen to have time to go look, 
what they remember about what they previously installed, etc.).


> > I think it would be much better to work on an installer package,
> > similar to the Windows installer package, that would package together
> > stable, tested, library and app releases.
>
> Well, call it as you like: installer package or core package, it is 
> still the
> same. Point is to have single GNUstep-Core package with some automated
> build/installation mechanism (script). However, it is not the same for 
> sources
> and binaries of course. Would be a binary package compatible for all
> distributions of linux, for example? I think if they managed Java to 
> be, i see
> no reason why GNUstep should be, but I do not see to the internals 
> much.

The gnustep.org packages are a fallback for users whose distribution 
does not package gnustep for them, or does not package a sufficiently 
recent version.  Thus, a source package would be preferable in offering 
broader support for user platforms than a binary one.