Re: NSPathUtilities Patch - 4 - NSPathUtilities.h

[Adam Fedor]

On Wednesday, April 21, 2004, at 03:23 AM, David Ayers wrote:
> I think breaking binary compatibility is something we should try to 
> avoid as much as we can.  Lots of folks have very extensive GNUstep 
> based projects installed and recompiling them is a real issue.  What I 
> think we are missing is some type of semi formalized procedure on how 
> to go about it and communicating this to our users.

Well, yes, unless it's a bug :-) But definetly we need a better way to 
communicate changes. Probably a ReleaseNotes document (like NEWS, but 
more extensive).

> I believe the in general we avoid breaking binaray compatibility for 
> minor releases and find some way to mark the places we want to clean 
> up for the next major release, in which we can break binary 
> compatibility.  (Note that I think the NSView patches which added 
> instance variables in -gui would by this logic require a major release 
> bump for -gui/-back).

We definitly need this for make/base, as the are considered 'mature'.  
I'd like to avoid that for gui/back until we get to 1.0 (whatever that 
is).

I also want to get away from the stable/unstable release numbers.  I 
tend to test the stable and unstable releases the same, but the rapid 
increase in release number doesn't really communicate how much has 
changed or why.


> Deciding on /when/ breaking binary compatibility is allowed, is 
> therefore delegated to the "release manager" who can simple announce 
> that the next release will be a major relaese and therefor anyone can 
> grep for the marked codes to do the actual cleanup.

I've avoided looking at this since it's so much work, but I guess what 
we need to do is allow binary incompatibility on the main branch (if 
necessary), but keep release branches around longer - backporting bug 
fixes and other things to the release branch, so users of the 'stable' 
releases can feel better about upgrading, etc...