NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Stuart, > Just a small request regarding the visad updates. Could there be some > form of incremental versioning? I have used visad for about 18 months > now and every single 'latest version' is called 2.0 ;) I can hear the > chat now "Hey, that new visad jar you installed broke my app, I'll need > to go back to version 2.0. Um, this IS version 2.0. Well, I want the > other version 2.0" and so on.... > > I appreciate the 'LAST UPDATED' link on the visad home page, but that is > of no help once you're using the library locally. It was my decision to label versions using the DATE file that's included in visad.jar and visad_src-2.0.jar (and LAST UPDATED is simply a dump of the date and time in the DATE file) rather than an incrementing version number. My decision was based on my experience with Vis5D, where we used version numbers. A file with the date and time of the build can be compared to dates and times in the CVS log and in the mailing list archive, whereas a version number is just an abstract number. During the first couple years of VisAD development (starting in about January 1998), we were posting VisAD updates sometimes daily (many fixes for critical bugs) and version numbers would have been a mess for us to maintain and a mess for users to keep track of. Dates and times seemed so much simpler for both. I think the biggest drawback of our approach is that it is not what people are used to with other software systems. Since the DATE file is included in both the source and the class file distributions, it can be used locally. Cheers, Bill
visad
archives: