Split the Extras into their own release tracks about growl HOT 19 CLOSED

I don't think we should do that until we have a built-in extra updater in the
prefpane. This could get really messy really fast on the website (we used to
distribute this way and it confused everyone, albeit the way we do it now is
confusing too)

We used to have separate disk images? I don't remember that.

I basically see us treating them as separate products. Separate disk images, a 
page with a list of all of the 
products, separate product pages, etc.

Ya, we used to in the .6 era. It made distribution harder (had to keep up with
multiple downloads and download pages), and people couldn't find things since 
they
only saw one or two things.

I think that version of the website is in svn if you want to check it out, but 
it's
probably not worth the time.

I don't disagree with separate releases on extras, I just think we could do it 
better
by having an extras tab, with an "Update" button for each extra. Thoughts?

The idea is basically to make Growl and the Extras peers, instead of keeping 
the Extras subordinate. Imagine, 
for example, a row of icons at the top, with Growl at the far left, followed by 
GrowlMail, GrowlSafari, 
GrowlTunes, and HardwareGrowler.

And I'd be fine with it, but I'm just seeing people having bigger problems.

What problem are you specifically trying to resolve here? The fact that extras 
have
to wait on Growl for a release? Or something else?

Yes. Specifically, GrowlMail.

Let's list out the pros and cons of doing this versus not doing this, and then 
of
doing this in 1.2.1 versus waiting for an extras tab. I'm not opposed if it 
makes
sense based on weighing the 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

Prefpane Extras tab:
- They're still one distribution, so all the cons there still apply
- 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: Increases release effort, since the Extras have to all go on the Growl 
disk image *and* be available 
separately from the website for the prefpane
- 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.

Corrections/Additions (imho) to the pros/cons list:


Breaking them into separate products:
- 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
- Pro: Easier to determine what extras are in use by download statistics
- Con: Major updates to website to change documentation and distribution pages

Prefpane Extras tab:
- I do not agree with "- They're still one distribution, so all the cons there 
still
apply" since releases of products are no longer chained together, and the 
versions
can be different.

Metapackage:

- Pro: We can still distribute an update to an extra out of band if so required 
to do
so, via the website.

Moved the list to the wiki under FutureGrowlInstallerPlusDMGPlans

We should do this for 1.2.2, or even 1.3.1. 1.2.1 should be just for 
localizations.

There are other bug fixes already in for 1.2.1, but yeah, this can wait.

GrowlMail is split off currently. We should split the rest and set up the 
Extras tab in 1.4.

[deleted comment]

This is the only feature I want to see in 2.1. Extras tab. This would resolve 
so many problems.

Making this a requirement for 2.1. We should leave the Extras as-is for 2.0, 
with GrowlMail split off.

We'll be doing this in 1.3 as part of targeting the App Store.

We're forced to do this as part of the app store move anyhow. It's obvious that 
the discussion in this ticket from 2009 is not really relevant anymore, Closing.