If I had that versioning history, I would seriously reconsider my way
of versioning my releases!
A more normal non-linear case would probably be:
1.0 -> 1.0.1 add property X
1.0 -> 1.1 add property X and Y
When 1.0.1 is deployed, *some* of the entities will be migrated to 1.0.1
When 1.1 is deployed, the persistent state will contain some rev-1.0
and some rev-1.0.1 entities.
We can just express the migration rules as:
* add property X to all 1.0 instances (thus upgrading them to 1.0.1)
* add property Y to all 1.0.1 instances (thus upgrading them to 1.1)
When we fetch an 1.0 entity, both migrations should be performed
before returning the entity to the client.
So in the normal case it is sufficient to base the migration on the
existing version (and remember to update the applicationversion on the
entity).
The only time I have seen a weird versioning scheme like George's was
a situation where 1.0.1 was "our product customized for customer 1"
and 1.1 was "our product customized for customer 2", but I believe it
is ok, if support for that is left out of Qi4J.
Kent
Den 18/09/2009 kl. 11.58 skrev Rickard Öberg:
Georg Ragaller wrote:
With a linear history this might be enough, but consider this
history:
1.0 -> 1.1 -> 1.2
| ^
---> 1.0.1 -|
1.0 -> 1.1 adds property X
1.0 -> 1.0.1 adds properties X and Y
1.1 -> 1.2 adds Y
1.0.1 -> 1.2 adds nothing
how should the 'toVersion("1.2")' rule then look like?
I've never seen non-linear version histories, especially not when it
comes to state in domain models. Even in the above case you really
would be upgrading 1.0->1.0.1->1.1->1.2, which makes the branch not
really different from the main.
But what is the reason 1.1 does not have Y? Are you saying that
1.0.1 has a feature Y that is then not available in 1.1, and is
readded for 1.2? That sounds weird...
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
