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 protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
