discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Package releases at homepage


From: Adrian Robert
Subject: Re: Package releases at homepage
Date: Mon, 31 Jan 2005 10:44:18 -0500


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.




reply via email to

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