On Nov 8, 2007 1:07 PM, Adam Fedor <[EMAIL PROTECTED]> wrote: > On a related note. It appears that the gui release will rely on base > >= 1.15.1
So what does that mean? Does gui 0.13.0 not work with base 1.14.1? (Just saw the new Library Compatibility page on the wiki, so yes) If that's the case, I don't think it's a good idea keeping things the way they are then. I generally make the Slackware packages that are on the FTP and what this current policy means to people packaging GNUstep is that they HAVE to follow GNUstep unstable no matter what since if you want to have a complete GNUstep environment you need base + gui. In my opinion, if you guys want to follow this release concept it would be intuitive to consider GNUstep as a whole not yet stable/1.x! I understand that this may not be desirable since base is stable, but if every new release of gui requires the latest unstable base, how can we expect any distribution to pick GNUstep up? If the above is out of the question, then I think the core developers need to reconsider the current stable and unstable thing. Something I've been meaning to bring up is why can't we just have a single release (as opposed to a stable + unstable): more frequent sub-minor/stable/ABI compatible releases (at least twice a year), change minor version number for ABI changes (every 18+ months), major version for API changes. If someone wants the latest unstable they can just pick up trunk, which is where unstable releases come from anyway. In all reality, this is what's been going on so far anyway, except with no sub-minor releases if you consider the 1.14.x branch unusable due to incompatibility with latest gui. This approach also does away with having to figure out which one is the unstable and which one is the stable release (since 1.14.xis ABI incompatible with 1.15.x which is incompatible with 1.16.x, etc). There are drawbacks to this approach, I know, but in my opinion it makes more sense than the current policy. Just my opinion on the subject. Thanks for reading what I had to say (or write) on the subject, Stefan
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
