On 2009-11-19 09:37+0100 Werner Smekal wrote:
> Hi list,
> I actually don't care about this number issues (it's ok for me if we
> go to PLplot 5.146), but wouldn't it be time to step to 6.0 any time
> soon? This time we could really branch PLplot and e.g. remove all
> drivers/code which are(is unmaintained. If someone wants to use these
> drivers/this code, he/she should either volunteer to maintain the
> driver or use the 5.x branch, which we could maintain for some time.
> My considerations are the following:
> * PLplot improved/changed a lot over the last years and it's time to
> show the users the the code changed considerably and isn't just "only
> * we could use this opportunity to remove code, which is not
> maintained anymore (Alan did already remove some code already)
> * we also should use this opportunity to streamline our efforts to
> raise the quality of the project overall.
> - e.g. documentation - for a 6.0 version we could try to improve
> the documentation
> - implement/fix bugs/features/requests on our trackers (also Alan
> started this already)
> - ....
> * we could also do some API changes, since it's a new version, so this
> might be the right time to do that.
> What I mean is, we could try to agree on a roadmap to a 6.0 version -
> if we implement everything (most of it) 6.0 is released. The timeframe
> wouldn't be anytime soon, but first we could discuss what should be on
> the roadmap and then try to streamline our efforts, i.e. a "bug
> hunting month" or a "documentation month" where all who have time,
> work mostly on one task. Normally these are "bug hunting days", but
> hey let's stay realistic ;). I don't propose that we should do a lot
> of code changes, since I think, that PLplot now already "deserves" a
> major version number change. My proposal is just, that we bring
> everything on par with the code and the make the 6.0 release. We could
> also (as Alan also already started) streamline our testing efforts, so
> that we identify platforms which we support. E.g. nobody of the
> developers here has access to Mac OS X 10.6 obviously so this wouldn't
> be a supported platform. Supported platforms should be tested
> regularily. If we identify all these tasks it would also be easier to
> apply for GSOC. Last year we were really to late to apply for anything.
> What do you think? Actually, most of that was already started/
> discussed by Alan, I just want to streamline the efforts and the
> result should be PLplot 6.0.
A major version bump (e.g., to 6.0) gives us a great opportunity to improve
our API, and I would like to take advantage of that opportunity. That
implies discussion about our "ideal" API and implementation and testing of
that implementation which will take considerable time (probably more than a
year). It also implies removing the non-ideal components of our API that
have been replaced/superseded by the "ideal" API. That removal is essential
to keep our API lean and focussed and new users undistracted by non-ideal
API. However, that removal is the backwards incompatible API change that
gets everyone concerned (since it generally means reprogramming of old apps
that use PLplot) so long notice is required of the major version bump that
removes non-ideal API after the ideal API is implemented and tested.
An excellent case in point is Hazen's recent "proof-of-concept"
implementation of plget & plset functions which should allow us to replace
many/all of the set and get functions in our current API. If everybody
likes that approach for our "ideal" API, then it needs to be propagated to
all our languages, all replacable pls* and plg* functions replaced with the
equivalent plset/plget in our examples for testing purposes, all replaceable
pls* and plg* functions moved to pldeprecated.c, and a notice in the release
notes that those replaceable pls* and plg* functions are scheduled for
removal at the next major version bump. That effort should be followed by a
complete stable release series (a series of development releases culminating
in a stable release) in the 5.x series. Such a complete stable release
series should prove the plset/plget concept completely and similarly for any
other "ideal" API additions we want to make to replace "non-ideal" API
functions that will be moved to pldeprecated.c.
Once we are happy with our "ideal" API we could just keep continuing with
5.x releases for a while with no removal of the non-ideal API. However, at
some point (where we feel enough notice has been given) we will want to
remove the non-ideal API since a bloated API becomes a
maintenance/documentation issue and distracts both developers and users over
the long haul. That removal of everything in pldeprecated.c (and associated
documentation and language bindings API) should be tested with a complete
stable release series (probably with a series of development releases
labelled 5.99.x which culminate in the 6.0 stable release).
So I think "the road to 6.0" is going to be a long process that will need
lots of planning, implementation, and testing work, but that effort should
be worthwhile if we end up with just the ideal API for 6.0 with the
non-ideal component of our API completely removed.
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project