Yes Venkat, we should do this and oozie is perfect example for this, which handles all the cases mentioned by ajay.
On Wed, Sep 16, 2015 at 8:12 AM, Ajay Yadav <[email protected]> wrote: > Thanks for initiating this discussion Venkat, I was about to start the same > thread :) > > Versioning is a great idea. I would like to add some more points to this > discussion. > > 1. XSDs of all version need to be maintained, just bumping up the > version alone is not sufficient. > 2. All the older xmls in the falcon code base need not be migrated to > latest xsd version. > 3. Version changes should be clubbed across the falcon releases, i.e. if > there are several changes in feed xsd between falcon 0.7 and falcon 0.8, > feed xsd version should be bumped up only once. > > > > > On Wed, Sep 16, 2015 at 6:56 AM, Venkat Ranganathan < > [email protected]> wrote: > > > Hi all > > > > There have been lots of great additions to the product and some of them > > are changing the schema definitions (mostly additions is what I have seen > > so far). But still, we need to have a plan to come up with a plan to > > handle XSD versioning so that it is easy to track features. I briefly > > mentioning this in the email notification JIRA that Peeyush is working on > > and also brought up during the Lifecycle discussions > > > > I think we should have a policy: Something along the lines below : > > subject to discussion, modification and updates by the community) > > > > XSD’s will have a major and minor version. > > When backward incompatible and/or significant new features are > > introduced in the XSDs, we should increment the major version > > Otherwise we will increment the minor version. Documents based only > > on minor version differences should be consumable by all Falcon product > > versions supporting that XSD version > > > > Thoughts? > > > > Thanks > > > > Venkat > > > -- Regards Pavan Kumar Kolamuri
