Well, actually, "_dev" means we haven't released that version yet. So the
next will be without _dev -- 13.3.4 and 13.4.4. I made the mistake last
release to increase the number as well, so that's probably what is throwing
you off.
13.3 is the "stable" version.
13.4 is the "development version.
Within those, we are going .1, .2, .3, etc. And a few months ago Jaime
suggested I add the dates to the dev subversions. I also decided to keep it
all synchronized so that 13.3.n was being produced at the same time as
13.4.n in terms of bug fixes. Now at http://chemapps.stolaf.edu/jmol/zip we
have a full record of the daily (subdaily?) changes in a flat directory.
That's working very well.
So 13.3.4 and 13.4.4 will be released momentarily.
Now, because of all that has to be done to put together jsmol.zip, I have
been just using 13.4.4 code for that. No "stable release" in terms of the
JavaScript. That said, I just got the workflow in place to very quickly (<
1 minute) go from Java testing of Jmol to fully created jsmol.zip. However,
I'm doing that specifically from 13.4. I'm not creating jsmol.zip from
13.3. I suppose I should do that since it's now so easy to compile. (Just
run buildfromjmol.xml and then buildtojs.xml.)
How important is it that we have a "stable" version of the applet that is
different from the "development" version?
On Thu, Aug 22, 2013 at 4:21 AM, Angel Herráez <[email protected]> wrote:
> **
> > 13.3.4, I think. But what I'm not distinguishing between 13.3 and 13.4
> for JSmol/HTML5, only the
> > Java versions.
>
> Well, if this is introduced in some 13.3.4_dev, I think the description
> to be safe should say the next subversion.Otherwise, somone with an older
> 13.3.4 may xpect it to work. That's why I said 13.3.5.
> We don't have 13.4 yet, do we? Maybe that's the one I should write as it
> is (will be) the release version that includes this feature.
>
> > It's important to note that one needs to use
> >
> > jsmol.min.nojq.js
>
> Ah, I thought that because of this change there would be no need for a
> vesion of jQuery embedded into Jmol and the would dispose of the dual
> "nojq" files. So then everything stays the same:
> jsmol.min.js for a standard deployment
> jsmol.min.nojq.js if on is using a separate jQuery
>
>
I think so. The problem, of course, is that technically now "JSmol.min.js"
maybe shouldn't include jQuery, but we're already down that path, and I'm
not so sure we want to suddenly remove jQuery from JSmol.min.js. Not
everyone wants to bother with finding the minimized version of jQuery; this
guarantees that we have one version working and tested and reliable.
> > if one wants to use one's own version of jQuery.
>
> Right, so what is the minimal version of that jQuery that includes those
> "recent improvements to jQuery" allowing Jmol to use the new extension
> method?
>
Good question. I know that jQuery.1.7 had a bug. That's what I started
with, and it did not work in Safari. It was this line:
xml = xhr.responseXML
So I had to go in and tweak jQuery just for that. Very annoying that that
was in the core AJAX method and couldn't be extended. That's also in
jQuery 1.8, but it is gone from jQuery 1.9. So I would say jQuery 1.9
should be recommended as a minimum version.
--
Robert M. Hanson
Larson-Anderson Professor 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
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
