One of the challenges with any provisioning solution is compatibility. Eclipse (the platform) has typically not supported 'forward compatibility', that is, there is no expectation that code written today should be able to process a data model developed tomorrow. However, backwards compatibility is typically very high on the Eclipse priority list.
With provisioning tools, backwards compatibility is valued high as well, but forward compatibility is almost essential. For example, if today's build of Eclipse cannot understand the repository that is produced tomorrow, then an update would be impossible. What is the model compatibility plan (both in theory and practice) for oomph? I understand that as the model is refined, there may be some breakage, but once that settles down, what expectations can we reasonably make? 1. Will newer versions of the installer (and Oomph tools) be compatible with previous models? (backwards compatibility). 2. Will the models evolve in a way to ensure that old tools can still read the newer models (even if the tools cannot act on all the elements in the model)? (forward compatibility) That is, if a model is updated (on the server) can we be confident that existing users will continue to function without the need for an update their oomph tools? Finally, is there some expectations we can (should) make between promoted builds and integration builds? For example, there is no compatibility expectations between integration builds but promoted builds should not break users? Cheers, Ian -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource
_______________________________________________ oomph-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/oomph-dev
