[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- From: James D Miles <jdmiles@xxxxxxxxxx>
- Date: Thu, 11 Oct 2007 11:30:19 -0500
- Delivered-to: email@example.com
From Questions for M3
"Should versions be pluggable (the current version does not properly reason about the version of the JRE"
JRE versions do go past the version definition that currently exists. I will only give you our experience using versions with the current update. Translate to the new terminology as needed.
We used the major number to create a hierarchy of different types of JREs. For instance we used 2.0.0 for j2se and 1.0.0 for jclDesktop. These were used for a parent feature. The child feature contained the actual JVM feature. This allowed us to provision JVMs like any other artifact. It allowed us to treat JVMs as equivalent from the ID perspective.
However it does not properly encapsulate the policy decisions that are necessary. If a platform initially specifies jcldesktop, version 1.0.0, then the user changes the JRE to J2SE, version 2.0.0, what gets done on an upgrade that specifies jclDesktop. So there likely needs to be another parameter/policy that specifies a user or platform choice (assuming either choice will resolve). In general updates only occur on versions. However IU with ID for jclDesktop does not equate to an ID for J2SE. The problem is how to know that they can replace each other.