That sounds good to me too. Plus if people want to build tools to do monitoring and reporting based on the schema itself, they feel safer doing that if they know there's this contract in place. (e.g. an intern wrote some code to look for anomalies in duration of jobs) Thanks! On Jun 27, 2012, at 5:10 PM, Alejandro Abdelnur wrote:
> Oozie i already doing a good job at keeping backwards compatibility for > user apps between releases, even if we add new functionality/features in > micro/minor releases. > > Micro/minor releases also carry critical fixes that are desirable > regardless of the new functionality/features. And we recommend users to > upgrade to the greatest latest to get their benefit. > > Making DB schema changes as part of a micro/minor update makes the upgrade > more complex (requiring a DB backup) and more difficult to undo in case of > an unexpected issue with the upgrade. > > Because of that I'd like to propose that DB schema changes should only be > done done as part of major upgrades (ie from 3.x to 4.x). > > Thx. > > -- > Alejandro
