candidate for beta4

Development
1

I’ve uploaded svn4225 as a candidate for beta4. (The one thing still missing
is the improved Bug Dialog from the demo I posted a bit ago.)

nomic.net/~uckelman/tmp/vassal/

Please let me know if you spot anything which is a regression from beta3.

2

I’m uploading svn4241 now, which contains the following changes over
svn4225:

  • We build an INDEX.LIST for Vengine.jar now, which might make class
    loading faster. (Or you might not notice any difference.)

  • xerces_2_5_0.jar is renamed to xercesImpl.jar, which is the name
    xalan-2.6.0.jar expects it to have, and is its proper name anyway. This
    was a prerequisite for being able to build an INDEX.LIST, and as a side
    effect you shouldn’t see a bad path warning from it when you compile
    now.

  • I’ve updated a whole bunch of JARs to their current versions:

    Updated BrowserLauncher to version 1.3.
    Updated swing-worker to version 1.2.
    Updated swingx to version 0.9.4.
    Updated smack to version 3.0.4.

The only one which I couldn’t update successfully is wizard.jar, since
the latest version (0.998.1) isn’t API-compatible with the version
we’ve been using. I’ll see about making the necessary changes for that
for beta5.

  • I’m building the Windows installer with NSIS 2.40 now (upgraded from
    2.39).

  • We’re not shipping pdf-transcoder.jar and js.jar anymore because we
    don’t use any part of Batik with uses them, so they’re just dead weight
    for us.

3

svn4250 incorporates the improved BugDialog as in the second demo, but
the “Send” button is live now.

nomic.net/~uckelman/tmp/vassal/

There are two things which which I want done for beta4 which will have
to wait for tomorrow:

  1. I intend to do something about the bad module/save data reporting.

  2. I’d like the periodic check for newer versions of VASSAL to be in
    beta4, so that it’s active across one pair of betas before we unleash
    it on the wider world.

I think I’ll be able to get these done tomorrow evening, so this build
is really, really close to beta4.

4

Does this mean when I start my copy of beta3 after that point I will be instructed to load beta4? Or only across release versions (I am guessing that would be a little pointless just yet though)? Or… is the pair of betas 4-5?

5

Thus spake “IrishBouzouki”:

Here’s a fuller description update checking:

Every n days (with a random initial offset), on startup, VASSAL checks
with the web site what versions are current. (Right now, I was thinking
of n = 10, but I don’t have any strong preference for that.) The set of
current versions is a point and a half-open interval (on the version
line). The point is the current release, and the half-open interval goes
from the current beta to infinity. So, if you’re equal to the current
release, or at least as new as the current beta, you’re current. (This
means that svn builds newer than the current beta are considered
current.) The suggested upgrade for any release is the current release.
The suggested upgrade for everything else (betas, svn builds) is the
current beta (which, might also be the same as the current relase,
since, e.g., immediately after we do a release there would be no
betas).

What the user will see in the case of being outdated is a simple
“yes/no” dialog asking whether he’d like to be taken to the download
page for the current version, and nothing in the case of being up to
date.

This has no effect on beta3 at all, since the logic for checking for
updates isn’t present in beta3.

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

6

Thus spake Joel Uckelman:

On reflection, it might be better to do something a bit more complex for
suggesting upgrades of non-releases: The suggested upgrade for a non-
release should be the current release, unless the non-release in
question is itself a newer than the current release.

The practical effect of this would be to nudge people running betas
and svn builds back to releases when they’re available.

–
J.

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

7

svn4255 contains the update checking code. An update check will be made
the first time you start the Module Manager after installing, and then
approximately every 10 days thereafter. (This is done on a background
thread, so in the event that you have no connection to the web site, it
won’t block you from using VASSAL.) If there is no newer version, you’ll
see nothing, which is what will happen when you install this build. If
there is a newer version, you’ll see a dialog which asks you if you’d
like to download it, and if you click “Yes” you’ll be taken to the
download page in your browser.

Alternatively, you can check for updates manually by selecting the
cleverly-named “Check for Updates…” item from the Module Manager’s
Help menu. If you choose this, you’ll be notified of the outcome
regardless of whether there are updates (but the dialog you see here
when there are updates is the same as the automatic one).

This build also incorporates a TurnTracker bug fix from Brent.

What’s left is to examine the bad module/save data reporting, so I
think we’ll be able to release beta4 by late this evening.