Re: Framework Major versions
Re: Framework Major versions
- Subject: Re: Framework Major versions
- From: Bill Cheeseman <email@hidden>
- Date: Tue, 19 Oct 2010 08:26:22 -0400
On Oct 18, 2010, at 8:12 PM, Nick Zitzmann wrote:
>>
>> and what should i do?
>
> You need to either move version A off to a separate project with the same target, or clone the target in the same project, with a new major version & its associated changes. Then you build both targets, and the framework versions will be merged with the same bundle. I think the "current" symlink is set to whatever version was built most recently.
>
> Keep in mind that framework versioning is usually unnecessary, unless you have added variables to a fragile superclass, or if you've removed some obsolete stuff that might still be in use by old code, or if a bug fix in the framework is causing regressions in existing apps, or something similar. IOW, you probably don't need to do this if you added new content, or if the framework is private & you also own the dependencies. So it would help to know why you want to do this...
I'm up to F in one of my frameworks, because I keep playing around with things that require a change in the major version. I didn't have to do this for the first few changes because I was the only one using the framework at that time, but I wanted to see how the mechanism worked. It works fine. So the framework as I distribute it publicly now only includes the last two major versions -- those that were public and might still be in use by others. I have tested the framework with old versions of my own applications that used old versions of the framework, and the versioning mechanism works just as the documentation indicates.
Here's what I do to include the old versions in a new release of the framework: I save the built executable, the headers, etc., from each previous framework separately in a safe place as soon as I've finished it. Later (maybe years later) I build the new version with only the new target, which keeps the process simple and as a side benefit ensures that the "Current" symlink points to the new version. Then, using a custom AppleScript script, I copy the old versions from the safe place into the built bundle and name them appropriately (A, B, etc.). I also use an AppleScript script to do the code signing correctly. This process is a bit idiosyncratic, to be sure, and it bypasses Xcode facilities that might be easier to use in some ways. But I have it down pat and use it for several products. Its primary benefit to me is that I can put away the source code for the old versions and never have to build them again -- thus preventing me from accidentally changing their code while I'm building the new version.
--
Bill Cheeseman - email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden