Re: migrations with multiple software versions
Re: migrations with multiple software versions
- Subject: Re: migrations with multiple software versions
- From: Pascal Robert <email@hidden>
- Date: Wed, 18 Jan 2012 17:14:41 -0500
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 (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden