Re: Installer project directory clarifications
Re: Installer project directory clarifications
- Subject: Re: Installer project directory clarifications
- From: Stéphane Sudre <email@hidden>
- Date: Mon, 26 Mar 2007 22:39:28 +0200
On lundi, mars 26, 2007, at 06:48 PM, Luke Bellandi wrote:
Hi Mike & Stéphane,
On Mar 25, 2007, at 11:57 AM, Stéphane Sudre wrote:
On dimanche, mars 25, 2007, at 06:20 PM, Mike wrote:
<snip>
But there's really no interest in creating a package per raw
components (application, associated frameworks, Application Support
sub folder, etc...)
Actually there is. Consider this example:
Let's say you're shipping a product that has an application and a
framework. You make 2 packages, one with the application and one with
the framework. You then make a distribution that installs both
bundles. Up to this point, this is functionally equivalent to putting
everything in one package, except that you will have two receipts:
receipt 1: MySoftware Application v1.0
receipt 2: MySoftware Framework v1.0
[...]
As you can see, method 2 gets messier as time goes on and you ship
updates to your software's components.
I'd suggest you spend some time considering what the most logical
divisions in your software product are, and create individual software
packages along those lines. It will make life much easier for you as
you ship updates to your software.
I should mention first that with method 2, I would personally not
follow the update strategy you describe. I would update the application
version if the frameworks needs to be updated and would provide a
complete package even for update without changing its name but just the
version (since the package version is in theory different from the
application version). Usually, if you need to fix a frameworks, it
would be surprising that you do not update the application itself at
the same time. This will result in a bigger archive, sure. But,
contrary to what the e-mails landing in my spam mailbox state, with OS
updates reaching 130 MB, size does not really matter a lot these days
for most users. Of course, YMMV if deployment is to be made on a big
local network or if DSL is still a Sci-Fi acronym where you live.
Some issues I can imagine with method 1:
1. If your OS requirements include 10.3 or earlier, you will not be
able to hide the fact that you have 2 components in your package and
this may introduce some confusion for the user.
2. Tech support might rather have the version of the application
updated along with the framework as it would allow them to track issues
more easily. Of course, you can put the frameworks version in the About
box as in Xcode. But who really provides this information every time
he/she filed a bug report against Xcode? I know I don't.
3. Finally, the user may end up installing a framework version that is
not compatible with the application.
But I'm probably wrong...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden