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 > maintained" > * 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.
Hi Werner: 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 __________________________ 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 (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
