Introduction

Installation sucks currently. Fix it.

Proposal for Change

By: Chris

The following proposal is based on a bit of thought about the whole distribution interaction.

I believe the following changes should be made:

1. Change the disk image to internet-enabled
2. Remove the webloc files from the disk image
3. Change the distribution to a pkg from a plain .prefpane sitting in a disk image
4. Remove the Extras directory
5. Remove everything from the main disk image except for the new Growl.pkg
6. Inside the prefpane have the extras
7. Have an Extras tab able to install the bundled Extras
8. Have an Extras tab that is able to check for updates on each of the Extras
9. Have a separate update file, or entry in a single file, for each Extra

From a distribution point of view, internet enabled is nice. You can push Growl down the pipe, it decompresses, and the user can execute it without having to deal with things like disk images. We no longer have users unable to dismount disk images.

We have to go with pkg, since we can't have Growl-1.prefpane and Growl-2.prefpane and so forth if we want to keep our sanity.

We do not go with a mpkg, since those can confuse users.

We already have code for decompressing a built-in file in the framework, we can convert that code to work for the Extras tab.

The general idea is to try to make this as easy as possible.

Pros and Cons

As a single collection of products:

• Pro: It's what we're already doing, so it has inertia behind it
• Con: Version numbers all move in lock-step (we used to not do this and it was unworkably complex)
• Con: Release of all products is chained together; if one product breaks, we have to rush to get the others release-ready to provide a fix
• Con: Users expect that updating the main product (Growl) will also update all of the Extras, which is not true
• Con: Easy for users to miss the Extras (no idea how common this really is)

Breaking them into separate products:

• Pro: Version numbers can move independently again
• Pro: Release of each product no longer chained to releases of the others; we can do an emergency update to one product (e.g., GrowlMail) without having to get others release-ready
• Pro: Users download and install each product separately, so they expect to update it separately as well (as they will, since updates will no longer come all together)
• Pro: Decreases release effort: Since we're only releasing one thing, we only have to build one thing (plus the framework)
• Pro: If we do the website right, presenting the Extras as peers to Growl (five separate product pages), users will know about all of the products, not just Growl
• Pro: Easier to determine what extras are in use by download statistics
• Con: Requires work on the makefile release system in order to implement this system
• Con: Requires update code in each extra to notify of updates
• Con: Major updates to website to change documentation and distribution pages

Prefpane Extras tab:

• Pro: Easy for users to update the Extras
• Con: Hard to do
• Con: Will increase traffic to the website as the prefpane gathers a list of Extras updates
• Con: May be even easier for users to miss the Extras, if the prefpane becomes the only way to install them

Metapackage:

• Pro: Simple installation (for users)
• Con: Really, really hard: PackageMaker shows no evidence of being able to do this, which means that if it's possible at all, we'd have to construct the metapackage manually
• Con: Version numbers all move in lock-step
• Con: Release of all products is chained together; if one product breaks, we have to rush to get the others release-ready to provide a fix
• Con: Doesn't address updating (would likely be combined with prefpane Extras tab)

The idea of solving these problems in 1.2.1 is to prevent us from potentially being behind every future update to Mail. Better sooner than later, since the longer we wait to do this, the more Mail updates may force us to release new GrowlMail updates.