From: Werner S. <sm...@ia...> - 2009-11-19 08:37:25
|
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. Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2009-11-20 01:26:48
|
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 __________________________ |
From: Werner S. <sm...@ia...> - 2009-11-23 19:41:08
|
Hi Geoffrey, > > If a new/improved set of Plplot Tcl/Tk widgets were to come along, > which > worked only with Tcl/Tk 8.5+, what would people expect to happen > with the > older stuff that works with Tcl/Tk 8.4-? > > If a new/improved set of PLplot Python widgets were to come along, > which > worked only with Python 3.1+ + Tcl/Tk 8.5+, what would people expect > to > happen with the older stuff that works with Python 2.6- and Tcl/Tk > 8.4-? Would it be okay to tell them to use the PLplot 5.x versions? I see this often in Open Source, that new versions of software only support the latest versions of its dependencies. So, if it's important for you to maintain compatibility with older systems, you need to stay with PLplot 5.x and if you want the new features of PLplot 6.x you need an OS with updated development tools. If we branch off PLplot 5.9 we could still provide some sort of support, like backporting of bug fixes or so. Also ask the users to adjust their code is not much too ask. e.g. for the wxWidgets library that's "normal". A change in the minor version number (e.g 2.6 to 2.8) means, that it's possible you need to change your code. Mostly these are small changes, but still the user can't anticipate that his code will compile "out-of-the-box". Sometimes people complain, but nobody forces you to use the new version. But if you want the new features of wxWidgets ... So, I think it's ok to raise also the minimal version number of dependencies required. Regards, Werner > > -- > Geoff > > ------------------------------------------------------------------------------ > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Angewandte Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Andrew R. <and...@us...> - 2009-11-23 19:59:10
|
On Mon, Nov 23, 2009 at 08:40:40PM +0100, Werner Smekal wrote: > Hi Geoffrey, > > > > > If a new/improved set of Plplot Tcl/Tk widgets were to come along, > > which > > worked only with Tcl/Tk 8.5+, what would people expect to happen > > with the > > older stuff that works with Tcl/Tk 8.4-? > > > > If a new/improved set of PLplot Python widgets were to come along, > > which > > worked only with Python 3.1+ + Tcl/Tk 8.5+, what would people expect > > to > > happen with the older stuff that works with Python 2.6- and Tcl/Tk > > 8.4-? > > Would it be okay to tell them to use the PLplot 5.x versions? I see > this often in Open Source, that new versions of software only support > the latest versions of its dependencies. So, if it's important for you > to maintain compatibility with older systems, you need to stay with > PLplot 5.x and if you want the new features of PLplot 6.x you need an > OS with updated development tools. If we branch off PLplot 5.9 we > could still provide some sort of support, like backporting of bug > fixes or so. > > Also ask the users to adjust their code is not much too ask. e.g. for > the wxWidgets library that's "normal". A change in the minor version > number (e.g 2.6 to 2.8) means, that it's possible you need to change > your code. Mostly these are small changes, but still the user can't > anticipate that his code will compile "out-of-the-box". Sometimes > people complain, but nobody forces you to use the new version. But if > you want the new features of wxWidgets ... > > So, I think it's ok to raise also the minimal version number of > dependencies required. I think it depends on the circumstances. If it is possible to maintain compatibility support for a while, then this is best. At some point though this becomes too much and support for obsolete versions has to be dropped. Things like tcl and python are particularly tricky here as there are often multiple versions in common use at any one time. I think we have to review things on a case by case basis. Where we drop support we need to clearly tell users about this well in advance so they have chance to migrate smoothly. Andrew |
From: Hazen B. <hba...@ma...> - 2009-11-29 01:07:32
|
Andrew Ross wrote: > On Mon, Nov 23, 2009 at 09:26:39AM -0600, Geoffrey Furnish wrote: >> Alan W. Irwin writes: >> > 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. >> >> Besides discussion of API changes and handling thereof, another thing which I >> find represents a large part of the PLplot adoption experience, relates to >> the third party packages and libraries we work with. >> > > A further thing for the wish list is to look over the drivers and see if there > are any we can no longer properly support. Alan has already done a lot of this > recently, but this might be a time for a code purge, as opposed to just > disabling by default. I would add return codes for every function in the API and moving away from the use of plabort() and plexit(). Also, I think that plget and plset are likely going to be a little baroque for everyday use in languages like C & Fortran. Compare: PLAttribute pen_attr; pen_attr.attributeType = PL_INT; pen_attr.intValue = 2; plset(PL_PENWIDTH, pen_attr); To: plwid(2); The goal of plget & plset is more or less complete coverage of the settable attributes of the current plot stream in form that is easily ported to all of our language bindings. I think we'll want to keep many of the functions currently in the API as "shortcuts". If we decide that a function is not used much we could remove it from the API & retain its abilities with plget/plset. If we decide that a stream attribute is accessed a lot via plget/plset then we could add a "shortcut" function to the API. -Hazen |