# Going forward: backward compatibility. **URL:** \ **Category:** Development\ **Created:** [February 18, 2008, 1:20am UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296 "2008-02-18T01:20:37Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![bsmith](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/bsmith/32/1_2.png) [@bsmith](https://forum.vassalengine.org/u/bsmith)\ **Post date:** [February 18, 2008, 1:20am UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/1 "2008-02-18T01:20:37Z")
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 ---
**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\ **Post date:** [February 18, 2008, 9:28am UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/2 "2008-02-18T09:28:40Z")
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](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![bsmith](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/bsmith/32/1_2.png) [@bsmith](https://forum.vassalengine.org/u/bsmith)\ **Post date:** [February 18, 2008, 12:54pm UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/3 "2008-02-18T12:54:18Z")
> [@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! ---
**Author:** ![mkiefte](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/mkiefte/32/25_2.png) [@mkiefte](https://forum.vassalengine.org/u/mkiefte)\ **Post date:** [February 18, 2008, 1:07pm UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/4 "2008-02-18T13:07:20Z")
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](mailto: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](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\ **Post date:** [February 18, 2008, 1:54pm UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/5 "2008-02-18T13:54:08Z")
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](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![Brent\_Easton](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/brent_easton/32/10_2.png) [@Brent\_Easton](https://forum.vassalengine.org/u/Brent_Easton)\ **Post date:** [February 19, 2008, 3:01am UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/6 "2008-02-19T03:01:10Z")
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](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![bsmith](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/bsmith/32/1_2.png) [@bsmith](https://forum.vassalengine.org/u/bsmith)\ **Post date:** [February 19, 2008, 4:30am UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/7 "2008-02-19T04:30:40Z")
> [@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? ---
**Author:** ![Brent\_Easton](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/brent_easton/32/10_2.png) [@Brent\_Easton](https://forum.vassalengine.org/u/Brent_Easton)\ **Post date:** [February 19, 2008, 4:47am UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/8 "2008-02-19T04:47:24Z")
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](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![bsmith](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/bsmith/32/1_2.png) [@bsmith](https://forum.vassalengine.org/u/bsmith)\ **Post date:** [February 19, 2008, 4:56am UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/9 "2008-02-19T04:56:47Z")
> [@](#): > > 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! ---
**Author:** ![bsmith](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/bsmith/32/1_2.png) [@bsmith](https://forum.vassalengine.org/u/bsmith)\ **Post date:** [February 19, 2008, 4:57am UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/10 "2008-02-19T04:57:14Z")
IN the module file… you know what I meant! ---
**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\ **Post date:** [February 19, 2008, 9:43am UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/11 "2008-02-19T09:43:33Z")
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](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![bsmith](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/bsmith/32/1_2.png) [@bsmith](https://forum.vassalengine.org/u/bsmith)\ **Post date:** [February 19, 2008, 11:39am UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/12 "2008-02-19T11:39:45Z")
> [@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. ---
**Author:** ![timpelican](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/t/e480ec/32.png) [@timpelican](https://forum.vassalengine.org/u/timpelican)\ **Post date:** [February 19, 2008, 12:03pm UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/13 "2008-02-19T12:03:48Z")
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](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![rk1](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/r/9f8e36/32.png) [@rk1](https://forum.vassalengine.org/u/rk1)\ **Post date:** [February 19, 2008, 12:14pm UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/14 "2008-02-19T12:14:08Z")
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](http://www.mail2forum.com)) ---
**Author:** ![bsmith](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/bsmith/32/1_2.png) [@bsmith](https://forum.vassalengine.org/u/bsmith)\ **Post date:** [February 19, 2008, 1:20pm UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/15 "2008-02-19T13:20:32Z")
> [@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](http://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](http://www.mediafire.com/?sharekey=aee67083e6162f8291b20cc0d07ba4d259d8e8a1358fbc04) > [@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. ---
**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\ **Post date:** [February 19, 2008, 2:08pm UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/16 "2008-02-19T14:08:49Z")
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](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![Rindis](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/rindis/32/14_2.png) [@Rindis](https://forum.vassalengine.org/u/Rindis)\ **Post date:** [February 20, 2008, 1:01am UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/17 "2008-02-20T01:01:16Z")
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. ---
**Author:** ![bsmith](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/bsmith/32/1_2.png) [@bsmith](https://forum.vassalengine.org/u/bsmith)\ **Post date:** [February 20, 2008, 2:50am UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/18 "2008-02-20T02:50:12Z")
> [@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. ---
**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\ **Post date:** [February 20, 2008, 10:58am UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/19 "2008-02-20T10:58:31Z")
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](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![timpelican](https://forum.vassalengine.org/letter_avatar_proxy/v4/letter/t/e480ec/32.png) [@timpelican](https://forum.vassalengine.org/u/timpelican)\ **Post date:** [February 20, 2008, 11:38am UTC](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296/20 "2008-02-20T11:38:35Z")
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](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) [Next page](https://forum.vassalengine.org/t/going-forward-backward-compatibility/296.md?page=2)