[GRASS5] Re: Backward compatibility (was PATCH: lib/imagery)

[Brad Douglas]

Can we come to some consensus before this drives me crazy?

On Tue, 2005-05-10 at 10:12 +0200, Radim Blazek wrote:
> Brad Douglas wrote:
> >>>>I post again.  It removes "struct Tape_Info" and related functions.  It
> >>>>also removes I_malloc(), I_realloc() and I_free() in favor of G_*().
> >>>>
> >>>>Any objections to me applying or did someone find a (legacy) use for the
> >>>>tape functions?
> >>>
> >>>None here.
> >>>
> >>>Also, as you have already identified the I_malloc/I_realloc calls, it
> >>>would be nice to remove the type casts. As G_malloc/G_realloc return
> >>>void*, the casts are unnecessary.
> 
> >>I am also in favour of code cleaning but is it safe to remove functions 
> >>from GRASS libraries during the 6.x line? Cannot that break backward 
> >>compatibility? GDAL for example is using libgrass_I.
> > 
> > 
> > Hmm.  I've had some discussion off-list with Glynn about lib/imagery
> > changes.  I asked Glynn if wee were in a full development cycle and he
> > indicated that we were.  Do we have a loose hierarchy as to who oversees
> > what?
> 
> What does it mean 'a full development cycle'? I don't believe we are in 
> such state after 6.0.0 release.
> 
> 'Loose hierarchy' sounds too strongly.
> 
> > In this particular case, I maybe one compatibility issue since I_malloc
> > () was the only function actually in use (IIRC).  None of the tape_info
> > structures/functions are in use anywhere (looks like support was dropped
> > in 5.x -> 6.x, but function definitions not removed).
> 
> I am almost sure that these changes cannot cause problems but we have to 
> follow some strategy. You cannot say 'non of the structures/functions 
> are used' because many users have developed their custom modules and we 
> cannot break their installations within 6.x.
> 
> >>I thought that we want to maintain binary compatibility for all 6.x 
> >>releases, is it right? If yes, what are the rules we have to follow?
> >>I thought that at least:
> >>- existing functions must not be changed, removed or renamed
> >>- structures must not be changed
> >>- constants and enumerations must not be changed
> > 
> > No problem.  I'm still quite new to the "flow" of GRASS development and
> > I seem to be getting different direction from different people.
> 
> The rules for compatibility maintenance probably were not explicitly 
> written. The only person here who can define them is Glynn.
> 
> In any case, such things should be discussed in the mailing list.
> 
> 
> Radim
-- 
Brad Douglas <rez at touchofmadness.com>