Going forward: backward compatibility.

[bsmith]

Now that we have a good Windows installer, we’re going to run into users who have multiple versions of Vassal installed simply because it’s so easy to do so!

A few things:

• We should make each future release backwards compatible.

• As you know, some modules require a specific version to run, should we require module designers to release a Vassal distribution with their module in the same way VASL does? This fixes the compatibility issue and means we don’t need to worry about Plugins as much. It also means we can install Vassal as it really should be installed, into the same folder the old version was installed in.

Thoughts?

Ben

[uckelman]

Thus spake “bsmith”:

A few things:

• We should make each future release backwards compatible.

This means that not only can’t we ever remove deprecated code, we have
to keep all of it working forever, too. We have a huge amount of deprecated
code these days. What I’d like to propose is that every time we release
VASSAL n+2, we purge all of the code which was deprecated during the release
cycle of VASSAL n. That gives module developers ample warning and doesn’t
impose an ever-increasing maintenance burden on us.

• As you know, some modules require a specific version to run, should we requ
  ire module designers to release a Vassal distribution with their module in
  the same way VASL does? This fixes the compatibility issue and means we don’
  t need to worry about Plugins as much. It also means we can install Vassal a
  s it really should be installed, into the same folder the old version was ins
  talled in.

Thoughts?

I disagree that VASSAL should really be installed into the same folder that
the old version was installed in. A big part of my motivation for creating
the Windows installer was to make it easier to have multiple versions of
VASSAL installed, and so that the user doesn’t have to care where they live
becuase Windows’ package manager (“Add/Remove Programs”) knows where they’re
installed.

–
J.

---

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

Post generated using Mail2Forum (mail2forum.com)

[bsmith]

@uckelman

I disagree that VASSAL should really be installed into the same folder that
the old version was installed in. A big part of my motivation for creating
the Windows installer was to make it easier to have multiple versions of
VASSAL installed, and so that the user doesn’t have to care where they live becuase Windows’ package manager (“Add/Remove Programs”) knows where they’re installed.

I understand the logic but… for some reason it just doesn’t feel right to me; I can’t think of another user-friendly piece of software which does it the way we are. Normally they’re backward compatible and just replace themselves when you install a new version. When you install a new version of Firefox, for example, you know and assume it’s going to overwrite the old version, but still keep your settings. Installing to a new folder every-time is not expected behaviour, unless you’re installing something like Eclipse or sendmail or hardcore IT stuff.

Also, I’ve got the feeling users are going to end up confused as to which version of Vassal they should be launching for a given module, and lazy module designers are not going to update their old modules.
I do want to feel comfortable about multiple version installs, but instead it’s making me nervous!

[mkiefte]

I don’t have a lot of experience with the VASSAL code, but it looks
like you guys have already done a good job of preserving a lot of
backwards compatibility, especially with the file formats. I know
there was an issue with the time tracker, but my understanding is that
this was something developed somewhat independently.

I don’t see an obvious problem with preserving backwards
compatibility. No one feature takes up so much code that if it became
deprecated would it really bog down the program. Can anyone actually
think of a case were backwards compatibility would be a bad idea?

• M.

On 18/02/2008, bsmith messages@forums.vassalengine.org wrote:

uckelman wrote:

I disagree that VASSAL should really be installed into the same folder that
the old version was installed in. A big part of my motivation for creating
the Windows installer was to make it easier to have multiple versions of
VASSAL installed, and so that the user doesn’t have to care where they live becuase Windows’ package manager (“Add/Remove Programs”) knows where they’re installed.

I understand the logic but… for some reason it just doesn’t feel right to me; I can’t think of another user-friendly piece of software which does it the way we are. Normally they’re backward compatible and just replace themselves when you install a new version. When you install a new version of Firefox, for example, you know and assume it’s going to overwrite the old version, but still keep your settings. Installing to a new folder every-time is not expected behaviour, unless you’re installing something like Eclipse or sendmail or hardcore IT stuff.

Also, I’ve got the feeling users are going to end up confused as to which version of Vassal they should be launching for a given module, and lazy module designers are not going to update their old modules.
I do want to feel comfortable about multiple version installs, but instead it’s making me nervous!

---

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

Post generated using Mail2Forum (mail2forum.com)

[uckelman]

Thus spake “Michael Kiefte”:

I don’t have a lot of experience with the VASSAL code, but it looks
like you guys have already done a good job of preserving a lot of
backwards compatibility, especially with the file formats. I know
there was an issue with the time tracker, but my understanding is that
this was something developed somewhat independently.

I don’t see an obvious problem with preserving backwards
compatibility. No one feature takes up so much code that if it became
deprecated would it really bog down the program. Can anyone actually
think of a case were backwards compatibility would be a bad idea?

• M.

I think we’re not all talking about the same thing—I’m speaking about
“API compatibility” for custom code. I think you (and maybe Ben) are
talking about file format compatibility, which I see no reason to break.
It’s not very hard to maintain file format compatibility, since all most
all of the code for that appears in the setAttribute() methods of
Configurables.

API compatibility I think is a whole different thing from file format
compatibility, for the maintenance reasons I mentioned.

–
J.

---

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

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

Ben,

• We should make each future release backwards compatible.

What exactly is your understanding of a future release being ‘backwards compatible’?

• As you know, some modules require a specific version to run, should we
  require module designers to release a Vassal distribution with their
  module in the same way VASL does? This fixes the compatibility issue and
  means we don’t need to worry about Plugins as much.

The vast majority of modules should not require any specific version to run. They should just run on the new version without any change. This is what I call backwards compatibility.

The modules with problems are invariable those that contain custom code. Part of the reason for Plugins is to make custom code more supportable and future-proof. However, the fact will always remain that any designer who uses custom code in their module will need to carefully check the function of their module against each point release and may need to update the module of it breaks. Custom code is by definition ‘outside the box’. However, custom code will ‘usually’ not break when Vassal is upgraded.

The TurnTracker situation was unfortunate, where major changes where made that broke the custom code and we where not aware how widespread it’s use was. We have learnt from that, but for custom code users, caveat emptor.

Brent.

---

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

Post generated using Mail2Forum (mail2forum.com)

[bsmith]

@Brent Easton

What exactly is your understanding of a future release being ‘backwards compatible’?

I have no understanding beyond the knowledge that Joel’s current Windows installer installs different versions of Vassal to different folders rather than just blowing away a user’s current version by default. So whether it’s custom code or whatever… I don’t like it that users should be made to keep track of what they’ve got installed and where. Seeing stuff like “3.0.17” scares a lot of people; As would having 4 different links to different Vassal versions on their desktop. I would like to think we’re making Vassal hard on users only if we really, really have no choice.

So I guess what I’m asking is:

• MUST Vassal install multiple versions? Is there no alternative?
• MUST we have users confused over which extensions and plugins they need to get hold of? It is going to scare casual users away, so is it essential?

[Brent_Easton]

Ben,

Brent Easton wrote:

What exactly is your understanding of a future release being 'backwards

compatible’?

I have no understanding beyond the knowledge that Joel’s current Windows
installer installs different versions of Vassal to different folders
rather than just blowing away a user’s current version by default. So
whether it’s custom code or whatever… I don’t like it that users should
be made to keep track of what they’ve got installed and where. Seeing
stuff like “3.0.17” scares a lot of people; As would having 4 different
links to different Vassal versions on their desktop. I would like to
think we’re making Vassal hard on users only if we really, really have
no choice.

OK, so it has nothing to do with ‘backward compatibility’ ? Phew

So I guess what I’m asking is:

• MUST Vassal install multiple versions? Is there no alternative?

Personally, I would favour not. We need to look at the average punter who just wants to install the latest and get going. Production versions of VASSAL should overwrite each other. Multiple VASSAL installations should be the exception to the rule for advanced users installing beta versions, or back-installing older versions.

• MUST we have users confused over which extensions and plugins they need
  to get hold of? It is going to scare casual users away, so is it
  essential?

No-one is holding a gun to module designers heads saying use extensions, so I’m not exactly sure what your point is? Perhaps some education for module designers on the pitfalls of using Extensions might be in order, rather than getting rid of them. Extensions are a useful tool in a tight, centrally controlled development enviroment. They are not necessarily such a good idea in a distributed development environment such as CW.

In the longer term, I hope that we can have some sort of auto-download and auto-update features for modules and extensions.

Regards,
Brent.

---

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

Post generated using Mail2Forum (mail2forum.com)

[bsmith]

No-one is holding a gun to module designers heads saying use extensions, so I’m not exactly sure what your point is? Perhaps some education for module designers on the pitfalls of using Extensions might be in order, rather than getting rid of them. Extensions are a useful tool in a tight, centrally controlled development enviroment. They are not necessarily such a good idea in a distributed development environment such as CW.

Could we force module designers to put the extensions on the module file itself maybe?

As long as anyone can design a module, we will be seeing shoddy module design. Just like educating people that smoking crack is bad, that’s not gonna stop people smoking it!

[bsmith]

IN the module file… you know what I meant!

[uckelman]

Thus spake “Brent Easton”:

So I guess what I’m asking is:

• MUST Vassal install multiple versions? Is there no alternative?

Personally, I would favour not. We need to look at the average punter who jus
t wants to install the latest and get going. Production versions of VASSAL sh
ould overwrite each other. Multiple VASSAL installations should be the except
ion to the rule for advanced users installing beta versions, or back-installi
ng older versions.

Having multiple versions of something installed concurrently is very
common in the Unix world. For example, the Fedora 8 Linux system on my
laptop has no fewer than five versions of automake and two versions of
Qt. If I wanted to have a different version of Firefox intalled beside
the one I’m currently using, I could do that without having to to do
anything special. I see the ability to try out a different version
easily without being forced to blow away older versions as an feature,
especially when there’s the possibility that old modules won’t work
with newer versions of VASSAL due to broken custom code.

If what you’re worried about is multiple versions accumulating, that
could be addressed by adding to the installer a prompt to remove them.

–
J.

---

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

Post generated using Mail2Forum (mail2forum.com)

[bsmith]

@uckelman

I see the ability to try out a different version
easily without being forced to blow away older versions as an feature,
especially when there’s the possibility that old modules won’t work
with newer versions of VASSAL due to broken custom code.

It’s a feature, and it should be the default feature only if we are going on the assumption the majority of Vassal users are IT knowledgeable. I’m personally working on the assumption that we’re trying to get average PC and Mac users playing board-games online with minimum frustration.

Unix users are generally power-users, they want to configure stuff at will, so it makes sense to favour flexibility over user-friendliness; But Windows and Mac, which the majority of users by far are using, are different.

I agree that the option should always be there to change the install folder, but the default install location should be the same location the last version was installed to. For example, on Windows it should be something like c:\Program Files\Vassal.
This would mean power-users can change the folder name if they like, but
normal users on their Macs and PCs can just hit the install button and accept all the defaults.

I feel pretty strongly about this, I’m so used to just clicking the “Install” button on Windows apps without having to do anything else; Other users will be the same. If I get my girlfriend (or are they called partners when you’re 36?!) to install Vassal, she’s going to wonder what the heck those version numbers are, because she’s never had to worry about them much before.

[timpelican]

On Tue, February 19, 2008 11:39 am, bsmith wrote:

I agree that the option should always be there to change the install
folder, but the default install location should be the same location the
last version was installed to. For example, on Windows it should be
something like c:\Program Files\Vassal.
This would mean power-users can change the folder name if they like, but
normal users on their Macs and PCs can just hit the install button and
accept all the defaults.

Well, Mac users just drag the file to where they want it, there is no
installer, but the same principle applies - they’ll over-write the old
version by default though.

I do agree with your expected behaviour though, and there is still a Mac
impact regarding directory naming for prefs, plug-ins, global extensions
etc.

I did already bring this up in a discussion with Joel as to where such
things should go in the Mac file-system, and I can see the value in
keeping things separated by major version number, as that’s usually where
any incompatibility problems are going to occur (witness people (myself
included) who still have 2.9.9 installed for various reasons).

My preference would be to see an over-write by default, maybe with a
tick-box in the installer for ‘keep old versions’ that automatically
generates a new install directory. Maybe a warning with an explicit
choice required to do / not-do this when either changing major version, or
installing a version older than the one in the default location?

Regards,
Tim.

---

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

Post generated using Mail2Forum (mail2forum.com)

[rk1]

The common case is certainly that people want to stay with the latest version, so that’s the case we want to make easiest. Making the install folder ‘VASSAL’ by default but letting people change it so that they can have two different versions installed makes sense.

I want to discourage module designers from packing a VASSAL release with their module because it will eat up storage and bandwidth on the server.

Module extensions are generally a good thing, but they do tend to splinter the module. I like that they let people experiment without churning the base module, but successful extensions should be re-integrated into the module. Here’s a cool idea: how about a tool in the module editor that reads in a module extension and adds those components directly to the module? Probably pretty straightforward to implement.

rk

Post generated using Mail2Forum (mail2forum.com)

[bsmith]

@rk

I want to discourage module designers from packing a VASSAL release with their module because it will eat up storage and bandwidth on the server.

I actually think module size is less of a problem these days thanks to free file hosting. Module sizes are getting bigger because user’s machines and broadband can better handle them. Have you seen MediaFire yet Rodney? I’ve got all of my modules hosted there, and I’ve noticed others are starting to do the same. It’s good because it tells you how many people have downloaded your module. I can see that my Case Blue mod has been downloaded 212 times

I’ve seen more and more modules being hosted there; Module creators are still using vassalengine.org to handle the links so people can find their modules easily. But there’s no stress on the server.

Check this out:

mediafire.com/?sharekey=aee6 … a1358fbc04

@rk

Here’s a cool idea: how about a tool in the module editor that reads in a module extension and adds those components directly to the module? Probably pretty straightforward to implement.

Yep, this sounds good to me; It would be nice to allow mod designers to package it all up easily. Two big thumbs up from me.

[uckelman]

Thus spake “bsmith”:

Installing to a new folder every-time is not
expected behaviour, unless you’re installing something like Eclipse or sendma
il or hardcore IT stuff.

I think this is a faulty distinction, because VASSAL is has more similarities
with this kind of program than you’re saying.

Because VASSAL is extensible, it falls somewhere between a self-contained
app and a language interpreter. For a self-contained app, you don’t expect
to have multiple versions installed because the app provides all of the
functionality itself and generally apps maintain backwards compatibility,
so you won’t need an older version of the app to read your older data.
Here, the user is dependend on only one set of delopers.

At the other end of the scale, you have language interpreters, where the
input could cause the app to do literally anything and generally the
interpreter developers and the developers of the program the user is using
are not the same. The interpreter developers don’t have any way to force
the program developers to keep their scripts up-to-date, so the user may
sometimes need more than one verson of the interpreter.

This is the situation we are in with respect to custom code in modules,
which tells me that multiple-version installations are going to be common.

I think there are two questions we need to resolve:

1. What should the default install location be?
2. How should the installer handle multiple versions?

Regarding #1:

In the case where a user intends to have only one version of VASSAL
installed and is upgrading, the default install location doesn’t
matter. In that case, the installer needs to uninstall previous
versions of VASSAL anyway, so the default install location should be
free whether we make it C:\Program Files\VASSAL or
C:\Program Files\VASSAL\VASSAL-3.1.0. I don’t see how the latter could
be confusing for users. The users who are potentially confused by this
are not the users who will be poking around in C:\Program Files
anyway. Most people will never be aware of what the installation
directory is named, so it cannot possibly confuse them.

(Further example: Acrobat Reader installs to
C:\Program Files\Acrobat\Acrobat x.y on Windows, even though you won’t
generally have multiple versions installed. I have never once heard
anyone say they were confused by this.)

In the case where a user intends to have more than one version of
VASSAL installed, having the default install location be
C:\Program Files\VASSAL\VASSAL-x.y.z is much better, because then
the user won’t have to provide any input in order to install the new
version somewhere safe.

So, regardless of what else the installer does w/r/t multiple
versions, the default installation path should contain the version
number.

Regarding #2:

Proposals I’ve heard so far are:
(a) uninstall older versions on new install, always
(b) uninstall older versions, except when a box is checked not to
(c) prompt user whether to uninstall older versions

I don’t like (a) for reasons I’ve stated above. The problem I see with
(b) is that it would be really easy to forget to check the box and
accidentally uninstall versions you want to keep. If the user is
presented with a dialog by the installer which says “You have other
versions of VASSAL installed. Would you like to remove them before
installing VASSAL x.y.z?” and given the choices “Yes” and “No”, I
don’t see how we could be clearer than that. (Or, a page in the
installer with radio buttons, instead of a dialog.) This should not
lead to users having multiple versions installed who don’t want that,
and it won’t hinder users who do.

Does this sound like a reasonable solution to everyone?

–
J.

---

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

Post generated using Mail2Forum (mail2forum.com)

[Rindis]

That sounds pretty good to me. I would recommend a checkbox per prior existing installation, so someone could do the equivalent of uninstalling 3.0.16 in favor of 3.0.17, while keeping 2.9.9.

So…
The following previous versions of Vassal have been detected on your system. Please uncheck any versions you wish to keep installed along with this one.
O Vassal 2.9.9
X Vassal 3.0.16

(I know I’ve seen a good example of this kind of UI choice, but I can’t think of where.)

Note, I feel the default should be to uninstall them. Multiple versions of Vassal is an “advanced option”, and those should not be default choices.

[bsmith]

@uckelman

I think this is a faulty distinction, because VASSAL is has more similarities with this kind of program than you’re saying.

Because VASSAL is extensible, it falls somewhere between a self-contained
app and a language interpreter. For a self-contained app, you don’t expect
to have multiple versions installed because the app provides all of the
functionality itself and generally apps maintain backwards compatibility,
so you won’t need an older version of the app to read your older data.
Here, the user is dependend on only one set of delopers.

At the other end of the scale, you have language interpreters, where the
input could cause the app to do literally anything and generally the
interpreter developers and the developers of the program the user is using
are not the same. The interpreter developers don’t have any way to force
the program developers to keep their scripts up-to-date, so the user may
sometimes need more than one verson of the interpreter.

This is the situation we are in with respect to custom code in modules,
which tells me that multiple-version installations are going to be common.

I agree with everything you’ve said but I’m acknowledging that it’s a problem. How do we hide the complexity of versioning so that Vassal is more accessible to more gamers? Users don’t care about this stuff, we’re talking about board game players here, they just want it to work.

An analogy: We’re going to have the greatest hair-dryer in the world, it’ll be able to dry a woman’s hair to perfection in 2 seconds on only 2 AAA batteries… Oh but I forgot to mention, women can’t use it because the handle is too big… That sucks I know, but if we give it a bigger handle, it won’t be the best hair-dryer in the world, so lets leave it as is!

C:\Program Files\VASSAL\VASSAL-3.1.0. I don’t see how the latter could be confusing for users.

The default install location entirely matters if we want users installing savegames and modules in a self-contained Vassal directory structure as discussed a while ago. This is one of the reasons multiple folder names is bad. I want to know that my modules are stored where Vassal is stored, all in one spot. When I upgrade Vassal, I want all of that stuff to still be there where I expect it to be and I want Vassal to know it. Putting it simply: When I upgrade Vassal, nothing will change. The link on my desktop will be the same, the folder will be the same, my modules and saves will be in the same spot. The only difference should be a tiny version number in a Help menu item somewhere.

If the user is
presented with a dialog by the installer which says “You have other
versions of VASSAL installed. Would you like to remove them before
installing VASSAL x.y.z?” and given the choices “Yes” and “No”, I
don’t see how we could be clearer than that.

A question as seemingly simple as “Do you want to remove previous versions?” is really going to confuse a lot of people. The first thing that will enter their head is “will it break any of the 30 modules I have installed?”. So right there we have a complete roadblock.

We’re getting warmer, but this still needs some thought. We need to to discuss this stuff as it’s pretty important.

[uckelman]

Thus spake “bsmith”:

The default install location entirely matters if we want users installing sav
egames and modules in a self-contained Vassal directory structure as discusse
d a while ago. This is one of the reasons multiple folder names is bad. I w
ant to know that my modules are stored where Vassal is stored, all in one spo
t. When I upgrade Vassal, I want all of that stuff to still be there where I
expect it to be and I want Vassal to know it. Putting it simply: When I upg
rade Vassal, nothing will change. The link on my desktop will be the same, t
he folder will be the same, my modules and saves will be in the same spot. T
he only difference should be a tiny version number in a Help menu item somewh
ere.

We’re not talking about the same thing—no way should data be stored
in the install directory. I’m not proposing that the place where the user
stores his modules and saved games change with each version of VASSAL.
All of that stuff should be in the user’s home directory, not in VASSAL’s
install directory. Mixing program files and data is asking for a mess.

A question as seemingly simple as “Do you want to remove previous versions?”
is really going to confuse a lot of people. The first thing that will enter
their head is “will it break any of the 30 modules I have installed?”. So ri
ght there we have a complete roadblock.

This is the whole point of asking the question! If you think you might
have this problem, then you should answer “No”. Blithely going ahead
with uninstalling old versions is only going to result in frustration
for this user when he discovers that he still needs that old version
the installer blew away.

If this hypothetical user is so easily confused, how do we expect him
to play the games for which he downloaded VASSAL in the first place?
How’s this guy going to figure the DRM for his attacks if he can’t
answer a question like “Do you want to keep or remove previous
versions of VASSAL?”

–
J.

---

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

Post generated using Mail2Forum (mail2forum.com)

[timpelican]

On Wed, February 20, 2008 10:58 am, Joel Uckelman wrote:

If this hypothetical user is so easily confused, how do we expect him
to play the games for which he downloaded VASSAL in the first place?
How’s this guy going to figure the DRM for his attacks if he can’t
answer a question like “Do you want to keep or remove previous
versions of VASSAL?”

Because the first is about boardgames, which he’s interested in, while the
second is about computers, which he isn’t.

I don’t know if you’ve ever worked front-line hel[lp]-desk, but you
cannot overestate the ease with which the brains of otherwise
exceedingly intelligent people can turn to blancmange when confronted with
an unfamiliar dialog box.

Cheers,
Tim.

---

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

Post generated using Mail2Forum (mail2forum.com)