Java version bug in 1.2.2 - Suggestion

[alistaircalder]

As a long-time software developer, I can tell you that releasing a build to your users on a Friday when no developers are around to provide a fix on the weekend is not advisable.

Especially a game. You have a lot of users who only have time to play on weekends, and no one available to provide a fix over the weekend.

I have some humble suggestions:

• Don't release on a Friday when you have no one to fix things on the weekend
• If you have to release on a Friday, at least allow users to downgrade
• Release on a Monday or Tuesday to leverage your userbase to test the build while developers are around to assess and fix any issues arising
• If a software or OS change is required, let the user know before suggesting an upgrade
• If a version check is required at load time, why not make one during the upgrade to ensure the user can run the app

This list is just meant as suggestions/feedback coming out of the 1.2.2 version number problem.

Thanks for listening.
A
edit: added a point

[arghman]

I concur.

I would also suggest that the central MULE server and future versions of the client be configured to use a server node/exchange/rendezvous point that is specific to the version of MULE (e.g. 1.1, 1.2.1, 1.2.2) etc., and the central MULE server be configured to allow older clients to run. Please do this rather than shut out users who can't run the latest version.

If two versions are interoperable (suppose that clients running 1.2.1 and 1.2.2 can communicate properly), then configure the central MULE server to let them interoperate. (e.g. behind the scenes, rendezvous point for 1.2.1 and 1.2.2 map to the same spot) If two versions are uninteroperable, let them be uninteroperable and let each have their own pool of inter-client communications. I would think it wouldn't be too hard to set up a service to act this way; Apache does URL rewriting all the time to handle resource mapping in this way.