old version warning and test builds

Here Ben describes the following problem: If you create a module with a test
build, then players who load the module with a release version of VASSAL
will get the following message:

“This module was created using version {0} of the VASSAL engine.
You are using version {1}
It’s recommended you upgrade to the latest version of the VASSAL engine.”

This is confusing for the average user, since he may already be running
the most recent release of VASSAL and be unaware that there are any test
builds. Furthermore, the test builds aren’t intended for the general
public anyway.

My response was that

(1) The message is being displayed in versions of VASSAL older than
the test builds, and we can’t change those. So whatever we do in the
short term has to happen in the test builds.

(2) Test builds could report their version number differently, so that
they don’t appear to be later than the last release, but then we could
end up with modules which claim to have been created with version X that
don’t run properly on version X, because they were really created with
version Y > X.

(3) We could change the message to say something else for modules created
by test builds. I guess that would solve the problem eventually, once
now-current versions of VASSAL were no longer in use.

Does anyone else have thoughts on how to handle this?

(I’m moving this discussion here so that it isn’t lost in the monster
thread about development builds.)

On Jan 9, 2008, at 3:11 AM, uckelman wrote:

Well, it would seem to me that one shouldn’t really be building
modules for release with test builds. Especially since there is the
possibility that the resulting module really will depend on some
feature of that test build that is not available in the general
release version.

The only problem with this is that it makes it tough to do good
testing of the test builds, since one would not want to invest a lot
of time in trying module construction if the results would have to be
repeated in a regular release.

I’m not sure what a good solution would be, other than some method of
making sure the test build version numbers end up being compatible
with the eventual release version. Maybe one way to do that would be
to have the main (and eventual release) version number be increased
with the test build, and to include other test-build version
information that is reported but not considered in comparisons. That
way, when the release version comes out it’s number will meet the
requirements.

Example:
Current release: 3.0.16
Test builds: 3.0.17 build 8
3.0.17 build 10
3.0.17 build 33
Next release: 3.0.17

This still doesn’t address the question of releasing a test build
constructed module to the general public. It would have to await the
release of the development on which it depends. But that is as it
should be, since that way you have some reasonable assurance that all
of the features are present. It isn’t fully guaranteed, since the
module could potentially depend on some artifact of a specific test
build that subsequently gets removed or changed, but it’s probably the
best we can do.

This will


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

Post generated using Mail2Forum (mail2forum.com)

Thus spake Thomas Russ:

If you save a module with a particular version of VASSAL, then the
module claims to have been created with that version—even if the
only thing you did was open the module and write it back out to disk.

There should be no issue of having to recreate modules—it just means
that a module last saved in a test build should eventually be saved in
an official release.

It already is this way. All of my 3.1.0-svn builds sort as later than
any 3.0 build, but before any 3.1.0 build.

True.

It’s interesting that this message appears only for modules saved in
newer versions of VASSAL, not saved games.


J.


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

Post generated using Mail2Forum (mail2forum.com)

On this point - Would be nice to have this info also for saved games/predefined setups. Dont know how many times Ive had to explain that previous saves or setups are not compatible (no new features of the upgraded mod unless predefined was rebuilt) to users.

Taking it a step beyond though :slight_smile: -
Even though the designer now has the saved game updater they can run after upgrading a mod so it is compatable with a module upgrade, (its kind of a pain when you have lots of setups) it really would be so much nicer if the saves/predefines auto upgrade themselves so the issue goes away entirely.

I realize that in these files some sort of info is stored regarding player side / security etc…and why it is thus, but it would be nice if that portion of the file be isolated somehow from the rest so that predefines and saves will still auto upgrade and gain latest features of gamepieces/layers etc.

I think it’s totally appropriate to have the warning there for test builds. If anything, incompatibilities are more likely with test builds so you want to make sure the user knows about it. If the warnings are truly obnoxious, we could make them better by writing to the chat window rather than throwing up a dialog.

There is a warning for saved games, but it checks the module version. It’s assumed that you don’t need to be running the same VASSAL version as your opponent so long as you’re both running a version that works with the module. That might not be strictly true, but it’s a fair bet.

rk

Post generated using Mail2Forum (mail2forum.com)