I would go with multiple DB schemas for different major versions. You will probably need that to have a different data sets to test against anyway.
> Hi all, > > I have a little scenario here and I was wondering if there was a way > the ERXMigration system could handle it. It looks like a "no" just reading > some of the docs, but I can't be the only one doing this (i hope). > > > So, I have two versions of software being worked on simultaneously. > The version 1 branch is stable with point releases introducing new features > and the version 2 branch is a fairly major revision simultaneously undergoing > major development. > > > ____version 1.0 _________ version 1.1__________ version > 1.1.1 ______________ version 1.2.0 > > ________/_________________.____________________________________________________________ > > \________________version 2.0 development > > > The question is... is there a good way to mange migrations with this sort of > setup? It seems like the migration system is really designed more to handle > a linear progression only. Is there even a way to spilt the migration > classes of a particular model into separate packages to better manage the > migrations across different versions of the software? I understand that as I > add things to the version 1 branch that there will be potential conflict in > the version 2 branch, but my question is more like do I start the version 2 > migration numbers at like 200 and leave room for ~90 potential future version > 1 migrations and if i did that does that mean I would need to create ~90 > actual classes that do nothing (obviously, this is not really a good > solution) > > > Any thoughts or ideas on this are appreciated. > Thanks. > > -Mike > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca > > This email sent to prob...@macti.ca _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
