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

[Hamish]

> > >>>>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.

Remove the relevant I_*() functions from the operational code but leave
the library functions in place, but never called.

If you are sure they are now unused, perhaps surround them with 

#define LEGACY_CODE
#ifdef LEGACY_CODE
int I_malloc()
#endif

so when we are in loose development mode it is clear what stuff is
scheduled to be ripped out and effects can be quickly enacted without
too much effort or risk. Adding a "depreciated" note to the Doxygen
comments is probably in order as well. Perhaps as a G_warning() as well
within the function so it is obvious if we missed any calls to it.


> > > No problem.  I'm still quite new to the "flow" of GRASS
> > > development and I seem to be getting different direction from
> > > different people.

yeah well... we've fallen off the end of the roadmap,
 http://grass.ibiblio.org/devel/roadmap.php
so I guess it needs some updating.


to add another sample point re. moving forward in all directions:

executive summary- I think the "will it break a script or plugin" 
test is a good one for current development.

[note to reader: long winded, no technical insights, feel free to move
on with your day without feeling you've missed anything at this point.]



My feeling is that the 6.0 series is very young and will be around for 
a while so we need to continue to let it stabilize and knock out more
bugs. e.g. if a new edition to the GRASS book is written for GRASS 6, it
would be good for the authors, readers, and students if the interface
was somewhat stable and the examples work as advertised, etc. Along
these lines the 6.0-beta series really demonstrated how well we could
concentrate effort onto fixing bugs when we were focused on doing so.

So at least try and make things backwards compatible back as far as the
6.0.0 release. I guess the main idea is that a script should be able to
be written for "GRASS 6" and work with any given version of "GRASS 6".
The code behind binary plugins shouldn't have to be changed between
minor releases (6.0.0, 6.0.1, ..., 6.0.26, etc.).

I think we should certainly keep the data formats interchangeable during
anything we call "6" but I'm not too concerned if an internal GRASS
6.0.0 library isn't 100% compatible with say version 6.2.0 (but others
might be; I'm no API guru). It is a courtesy to others like QGIS/GDAL/R
plugins to not break things with every minor point release, although
that is probably not often enough to get too ugly (I mean between 6.0.x,
6.2.x, etc.). But again, just my US$0.0146.

The trick is to find the sweet spot where you don't stall development so
much so that updates get forgotten and abandoned, motivation moves
somewhere else, etc.. Maybe a Wiki or CVS page of things TODO once
development mode is wide open? We would have to define what version (if
not when by date) that will be. In the past these TODO lists have been
scattered and not well advertised, ie ignored. Perhaps it would be
useful to have a TODO directory of sorts pointing to the different docs
& readmes in the wiki, with links to where the files are in the CVS
tree. I prefer the clear history CVS provides to an open wiki for the
actual files for two reasons: a) when a release is made it becomes
frozen in time & you can cross reference the code, and b) otherwise it
might as well be a unofficial wishlist-tracker.

You can fundamentally fix more bugs by condensing and cleaning the code
base, but you do risk breaking lots of things in the short term.



Hamish