The plan is to leave the daily binaries up on SourceForge UNLESS there is a
critical error that necesitates removing one from consideration. I hope not
to have to do that. Bear with me if I do. I suggest giving 24 to 48 hours
buffer between your loading the latest version into the MacPort if possible.
I will check the ANT task and see if it is adding to or overwriting the
directories. Maybe it is deleting older versions. But I don´t think it is,
as there are two daily versions in
http://sourceforge.net/projects/jmol/files/Jmol/Version%2014.0/Version%2014.0.17
I think it is important to do it this way. It has worked far better for me
to have the date stamp in the version. If necessary we can increment the
third component every time, but sometimes these are coming so fast, more
than one per day, that I hate to do that.
I am sensitive to the issue, but it is possible to infer the latest version
from the page based on the Looking for the latest version link.
Bob
Bob
On Fri, Jun 20, 2014 at 7:44 AM, Rolf Huehne <[email protected]> wrote:
> On 06/20/2014 12:49 PM, Angel Herráez wrote:
> > Peter,
> >
> > Daily releases at StOlaf server are certainly not something to point
> > to in an automated way, in my opinion.
> > You should only target releases at SourceForge, which are not so
> > frequent and do no disappear --at least if they are not broken.
> >
> Angel, I don't think Peter is referring to releases at StOlaf.
> Quote:
> "1) Leave all daily binaries up on sourceforge."
>
> The version numbering scheme was changed, including now a date stamp
> after the three numbers. This is reflected necessarily also at
> sourceforge. Otherwise the file names wouldn't be unique for a specific
> release.
> Example
> (
> http://sourceforge.net/projects/jmol/files/Jmol/Version%2014.0/Version%2014.0.17/
> ):
> Jmol-14.0.17_2014.06.11-full.tar.gz
> Jmol-14.0.17_2014.06.10-full.tar.gz
>
> Including a date stamp into a version numbering scheme is kind of a
> nightmare for people (like Peter) who have to keep track of new versions
> automatically because new version numbers become unpredictable.
> (I know what I am speaking of because we maintain a number of automatic
> updates from external databases used as data sources for our 3D
> structure database JenaLib. Finding new releases automatically can be
> such a pain!)
>
> I can see that it might be helpful for a developer to include a date
> stamp because it might make it easier not to mix up different versions.
> Especially if they are emerging very frequently.
> But besides the question if a date stamp should be part of a version
> numbering system, there is also another point:
> Is it really necessary to add a fourth level? Aren't three levels
> already a lot and already sufficient?
>
> Regards,
> Rolf
>
> --
>
> Rolf Huehne
> Postdoc
>
> Leibniz Institute for Age Research - Fritz Lipmann Institute (FLI)
> Beutenbergstrasse 11
> 07745 Jena, Germany
>
> Phone: +49 3641 65 6205
> Fax: +49 3641 65 6210
> E-Mail: [email protected]
> Website: http://www.fli-leibniz.de
>
> Scientific Director: Prof. Dr. K. Lenhard Rudolph
> Head of Administration: Dr. Daniele Barthel
> Chairman of Board of Trustees: Dennys Klein
>
> VAT No: DE 153 925 464
> Register of Associations: No. 230296, Amtsgericht Jena
> Tax Number: 162/141/08228
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Jmol-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
--
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
