Mworks MWorks Core Components

Comments and changes to this ticket

• 

  David Cox May 10th, 2010 @ 10:54 PM

  • Assigned user set to “David Cox”

  You're welcome to make separate "Application Folder" builds for your users, but it looks pretty ghetto/remedial from where I'm sitting.

  Is there a reason for this aside from superstition? Seems weird to go through all of these non-standard contortions when an uninstaller would just need to remove a handful of directories (in highly standardized locations) from a simple manifest. Is there some concern that such an uninstaller could not be reliably written? If so, we have deeper problems.

  And unless we screw things up, for all intents and purposes just throwing away the applications themselves would effectively allow an unsophisticated user get rid of that version, since the framework and app support versions would be baked into the .app's.

• 

  David Cox May 10th, 2010 @ 11:06 PM

  One other note: having multiple versions installed can also cause problems, e.g. if you (or your student/tech/etc.) accidentally run a version other than you intended. One weak protection we might consider would be having the version name tacked on to the app itself (e.g. "MWServer 0.4.4.app" rather than "MWorks/0.4.4/MWServer.app"). This would provide some indication in the dock of which version you are using, and might help prevent choosing the wrong version in Quicksilver/Alfred/etc.

  Another option would be make the multiple version thing optional. Other applications get by just fine without going to these lengths (though it is common for major versions to be installable in parallel, e.g. CS4, CS5).
  

  I know I'd prefer not to pollute my setups with multiple versions at once if I can help it... from my perspective it seems like an accident waiting to happen.

• 

  Christopher Stawarz May 11th, 2010 @ 03:07 PM

  Is there a reason for this aside from superstition?

  For me personally, it's not about superstition but rather paranoia :)

  Whenever I run an installer (especially one that asks for admin authentication), I think to myself, "Oh, god, what kind of garbage is this P.O.S. going to scatter all over my filesystem?" It'd be a different story if there were a standard way to fully uninstall a package. As it is, though, the best you can do is hunt down and read the package's bom and remove the installed files by hand.

  Compare that to the wonderful simplicity of a self-contained app bundle. To install, I drag the bundle to /Applications. To uninstall, I drag the bundle to the Trash.

  Of course, even if we did dump all MWorks components into a single directory, we'd probably still need to use an installer in order to support optional components and run installation scripts (e.g. to create setup_variables.xml if needed). And as you say, we can easily write (and have written) an uninstall script that does a thorough cleanup.

  FYI, John Gruber wrote an interesting essay on Mac app distribution methods. While it doesn't provide any specific answers for our situation, it's a worthwhile read.

  And unless we screw things up, for all intents and purposes just throwing away the applications themselves would effectively allow an unsophisticated user get rid of that version, since the framework and app support versions would be baked into the .app's.

  That isn't true currently: The frameworks are always installed as version "A", and app support isn't versioned at all. What you describe is basically my second option, except that there'd only ever be one version of each application. That's another route we could take, although I'm not sure what the advantage would be. (Like you said, if none of the applications link to a given framework and app support version, that version is effectively uninstalled.)

  One other note: having multiple versions installed can also cause problems, e.g. if you (or your student/tech/etc.) accidentally run a version other than you intended.

  Yeah, that's a real issue, and it relates to this ticket. Currently, if you have another copy of an application (e.g. MWServer) installed anywhere on your system (not just in /Applications), the installer simply won't install a new copy. Worse, if it does install a new MWClient, and you then try to launch the server from it, it will open the existing, old version of MWServer.

  I think the installation problem can be solved by updating CFBundleVersion appropriately for each release. However, there are other problems you can run into if you have multiple versions installed (e.g. launching a new MWServer from an old MWClient). That's definitely not a situation we want to get in to.

  In the end, the only really compelling reason to support multiple installed versions is to make it easier for people to test new releases. However, it's not clear to me that this would necessarily have the desired effect of getting more people testing new versions. Those who don't want to upgrade probably won't try anything new no matter how easy we make it, so maybe this isn't worth the trouble.

• 

  David Cox May 11th, 2010 @ 03:35 PM

  That isn't true currently: The frameworks are always installed as version "A", and app support isn't versioned at all. What you describe is basically my second option

  Yeah, yeah, I know. I was arguing for your second option.

  I'd love it if we could have a simple .app-contained bundle, but we have library dependencies that span the server and client, and configuration has to live somewhere separate anyways. We just don't seem to be good candidates for this style of build as a normal matter of course.

  In the end, the only really compelling reason to support multiple installed versions is to make it easier for people to test new releases.

  Maybe there's some kind of hybrid "trial" strategy that could work. Just brainstorming here. We could have an alternate build style where the apps all get named with their version in their name (e.g. "MWServer Preview 0.4.5"), and with everything self contained. For all normal builds, we use the "normal" style and work hard to ensure that there aren't multiple versions installed in this way that could be easily confused. For sampling new versions, you could use the alternate "preview" build, which can happily coexist with the default version (because it is chained to its enclosing dir) and which is impossible to mistake for the "ordinary" one (big "preview" splash screen, etc. etc.). This might let people dip their toes in a safe way, without inadvertently introducing a more dangerous situation stemming from multiple versions being available on the same system.

  Implementation-wise, this could probably be done with an alternate xcconfig, though it would almost certainly be a chore to setup. Might not be high priority, but perhaps nice in the long run.

• 

  Christopher Stawarz April 8th, 2011 @ 10:18 AM

  • State changed from “new” to “invalid”
  • Assigned user changed from “David Cox” to “Christopher Stawarz”
  • Milestone order changed from “0” to “0”

  I think the combination of archiving the old version during installation and providing an uninstall-and-revert script has effectively assuaged upgrade anxiety for most users, so there should be no need to implement any of these ideas.