Re: [Plplot-devel] library version

[<jc...@fe...>]

On Wednesday 05 February 2003 17:17, Alan W. Irwin wrote:
| On Wed, 5 Feb 2003, Rafael Laboissiere wrote:
| > I have a mission on earth: to avoid propagation of misunderstanding
| > of the purpose of library versioning.  Please, help me to achieve
| > that :-)
|
| I am going to take this discussion to the list.
|
| I asked for library version discussion before the 5.2.0 release, but
| nobody cared at the time.  So I think all of us will probably go
| along with whatever you decide. Note, I don't want to be involved in
| the decision making on library version because I don't have the time
| to keep track of what kind of API change occurred since the last
| release for each and every library.  I know that is sloppy, but I am
| already too overloaded with PLplot stuff.
|
| If you decide to go forward with this change, you should remember
| libtclmatrix is completely independent so it potentially should have
| independent version numbers. I am not sure whether our other
| libraries should have common version numbers or not, but you should
| check that.

I think they must, as they reflect the main library API.

|  If you decide to keep track of the API changes for each
| library, I presume you should make a decision about library version
| numbers for each library and commit that result roughly a week before
| release.  I would definitely welcome your effort on this, but if you
| don't have time for that, I fully understand because I don't have
| time for it myself....;-)

I don't have the original e-mail, but isn't enought to watch if plplot.h=20
has changed from the last release, and if yes just look at the loged=20
messages? API changes are generally well documented, and we could=20
enforce this, requiring that the log message includes the text "API=20
change".

| An alternative to the maintenance effort of keeping track of all API
| changes for each library is we could always blindly increment the
| major library version number for each and every release.

That would simplify our work, sure, just to complicate users work, as=20
they have to recompile all theirs apps each time they upgrade.
Till now, they don't have to recompile; if suddendly an app stops=20
working, then the user will remember "ah, I have upgraded plplot, lets=20
recompile".

|  That is
| roughly compatible with reality which is there is always some API
| change for most releases.

I have just now looked at the log messages since 5.0.1 and it is clear=20
at a first look that the library should have changed version for each=20
release.

Joao

| The only downside I can see of blind major
| number incrementing is we may soon get to library versions in the
| teens or even in the twenties, but at some point I am sure it is
| possible to recycle again and start back at the minimum library
| number (1.0.0?).  In fact, as far as I am concerned, we could start
| at the minimum library version number for the next release to
| emphasize the point that it is different from the package version.
|
| Alan
| __________________________
| Alan W. Irwin
| email: ir...@be...
| phone: 250-727-2902
|
| Astronomical research affiliation with Department of Physics and
| Astronomy, University of Victoria (astrowww.phys.uvic.ca).
|
| Programming affiliations with the Canadian Centre for Climate
| Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot
| scientific plotting software package (plplot.org).
|
| __________________________
|
| Linux-powered Science
| __________________________
|
|
|
| -------------------------------------------------------
| This SF.NET email is sponsored by:
| SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
| http://www.vasoftware.com
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel