[DISCUSS] Apache Falcon 1.0 release

[Ajay Yadava <aj...@apache.org>]

Hello everyone,

For quite some time we have been discussing to make a 1.0 release and have
had several discussions in developer sync up around it. Taking this to next
step, I propose next release line(after 0.10) of Apache Falcon to be 1.0


*Item 1 - Scope and Timelines*
Some of the items that are in works and I personally feel will be idle
candidate for 1.0 are - clean up our APIs(add a new version), introduce a
new shell for Falcon feed sla alerts, and move to the more powerful and
capable lifecycle framework for feeds among few.

After lot of thought and discussions with several members, I propose to not
aim for too many big features and a timeline of 2.5-3 months after the 0.10
release. This will ensure that critical fixes are not delayed and there is
only one active working line for code. We can add more features if other
community members are able to get them committed in time and our quality
team also feels comfortable.


*Item 2 - Migration Strategy*
While some of the changes like REST API clean up etc. can be done by adding
versioning others like migration to lifecycle framework etc. are bit more
involved. One important decision to be made is how to migrate to 1.0
release.

Here are some of the options to migrate to new entity definitions in 1.0
(NOTE: REST api can be versioned and same end points can continue to work
albeit with newer definitions)

*Approach 1*. Take a one time hit, call the release backward incompatible
and provide changes inside falcon to automatically migrate to newer
definitions on start up. We can support this migration code for a couple of
releases and then later on remove it.

 pros:
- Clean and easy to code -  no if else etc. for supporting features in
multiple manners.
- Intuitive for users - multiple options for same purpose are confusing for
the users.
- Easier to maintain - All bug fixes need to be done only in one code flow
and not at many places.

cons:
- involves migration - it can be automated by incorporating the migration
as part of falcon startup.


*Approach 2*. Support both old and new entity definitions.
pros
- users can work with both versions and migrate at their own pace

cons
- Hard to maintain - Lot of code will need to be duplicated (validations
etc.) or branched (wf builders etc.) All bug fixes will need to be fixed in
multiple places.
- Not scalable approach - The code will not scale easily if we decide to
support one more version.
- Manual migration - Users will have to migrate themselves to the new
entity definitions.
- Gotchas - What will happen if someone submits in newer version but calls
update in older version?


I invite all of you to provide your thoughts on both the items. There might
be more approaches or points to consider, suggestions are welcome.


Cheers
Ajay Yadava

Re: [DISCUSS] Apache Falcon 1.0 release

[Praveen Adlakha <pr...@inmobi.com>]

Hi All,

I believe Approach 1 looks more cleaner and hassle free.

Thanks
Praveen

On Wed, Apr 6, 2016 at 12:13 AM, Ajay Yadava <aj...@apache.org> wrote:

> Hello everyone,
>
> For quite some time we have been discussing to make a 1.0 release and have
> had several discussions in developer sync up around it. Taking this to next
> step, I propose next release line(after 0.10) of Apache Falcon to be 1.0
>
>
> *Item 1 - Scope and Timelines*
> Some of the items that are in works and I personally feel will be idle
> candidate for 1.0 are - clean up our APIs(add a new version), introduce a
> new shell for Falcon feed sla alerts, and move to the more powerful and
> capable lifecycle framework for feeds among few.
>
> After lot of thought and discussions with several members, I propose to not
> aim for too many big features and a timeline of 2.5-3 months after the 0.10
> release. This will ensure that critical fixes are not delayed and there is
> only one active working line for code. We can add more features if other
> community members are able to get them committed in time and our quality
> team also feels comfortable.
>
>
> *Item 2 - Migration Strategy*
> While some of the changes like REST API clean up etc. can be done by adding
> versioning others like migration to lifecycle framework etc. are bit more
> involved. One important decision to be made is how to migrate to 1.0
> release.
>
> Here are some of the options to migrate to new entity definitions in 1.0
> (NOTE: REST api can be versioned and same end points can continue to work
> albeit with newer definitions)
>
> *Approach 1*. Take a one time hit, call the release backward incompatible
> and provide changes inside falcon to automatically migrate to newer
> definitions on start up. We can support this migration code for a couple of
> releases and then later on remove it.
>
>  pros:
> - Clean and easy to code -  no if else etc. for supporting features in
> multiple manners.
> - Intuitive for users - multiple options for same purpose are confusing for
> the users.
> - Easier to maintain - All bug fixes need to be done only in one code flow
> and not at many places.
>
> cons:
> - involves migration - it can be automated by incorporating the migration
> as part of falcon startup.
>
>
> *Approach 2*. Support both old and new entity definitions.
> pros
> - users can work with both versions and migrate at their own pace
>
> cons
> - Hard to maintain - Lot of code will need to be duplicated (validations
> etc.) or branched (wf builders etc.) All bug fixes will need to be fixed in
> multiple places.
> - Not scalable approach - The code will not scale easily if we decide to
> support one more version.
> - Manual migration - Users will have to migrate themselves to the new
> entity definitions.
> - Gotchas - What will happen if someone submits in newer version but calls
> update in older version?
>
>
> I invite all of you to provide your thoughts on both the items. There might
> be more approaches or points to consider, suggestions are welcome.
>
>
> Cheers
> Ajay Yadava
>

-- 
_____________________________________________________________
The information contained in this communication is intended solely for the 
use of the individual or entity to whom it is addressed and others 
authorized to receive it. It may contain confidential or legally privileged 
information. If you are not the intended recipient you are hereby notified 
that any disclosure, copying, distribution or taking any action in reliance 
on the contents of this information is strictly prohibited and may be 
unlawful. If you have received this communication in error, please notify 
us immediately by responding to this email and then delete it from your 
system. The firm is neither liable for the proper and complete transmission 
of the information contained in this communication nor for any delay in its 
receipt.

Re: [DISCUSS] Apache Falcon 1.0 release

[Ying Zheng <yz...@hortonworks.com>]

+1 Approach 2 with auto converts as Srikanth also suggests. In this way
users don’t need to worry about the migration of older version to new one.

+1 Balu’s point on the guarantee of major feature shipping in 1.0 release
(e.g. UI, lifecycle framework). Server-side extensions (aka recipe) could
also be a big selling feature for Falcon. Similar products in different
areas, e.g. Chrome Extensions, App Store, are big success and proved to be
very useful already :)

Cheers,
Ying


On 4/6/16, 11:25 AM, "Balu Vellanki Bala" <bv...@hortonworks.com>
wrote:

>Hello Team, 
>
>Here is my 2 cents,
>
>Item 1 : "Apache Falcon 1.0² is a major milestone for the top level
>project and I sincerely think that it is important to have a good, easy to
>use UI as part of the release. Versioned APIs and Lifecycle framework are
>features we should definitely aim for in 1.0 release. If this pushes the
>timeline by a few weeks, I think the reward will be worth the delay.
>
>Item 2 : I agree with Srikanth¹s suggestion and reasons to go with
>approach 2. 
>
> 
>Thank you 
>Balu Vellanki 
>
>
>On 4/5/16, 11:43 AM, "Ajay Yadava" <aj...@apache.org> wrote:
>
>>Hello everyone,
>>
>>For quite some time we have been discussing to make a 1.0 release and
>>have
>>had several discussions in developer sync up around it. Taking this to
>>next
>>step, I propose next release line(after 0.10) of Apache Falcon to be 1.0
>>
>>
>>*Item 1 - Scope and Timelines*
>>Some of the items that are in works and I personally feel will be idle
>>candidate for 1.0 are - clean up our APIs(add a new version), introduce a
>>new shell for Falcon feed sla alerts, and move to the more powerful and
>>capable lifecycle framework for feeds among few.
>>
>>After lot of thought and discussions with several members, I propose to
>>not
>>aim for too many big features and a timeline of 2.5-3 months after the
>>0.10
>>release. This will ensure that critical fixes are not delayed and there
>>is
>>only one active working line for code. We can add more features if other
>>community members are able to get them committed in time and our quality
>>team also feels comfortable.
>>
>>
>>*Item 2 - Migration Strategy*
>>While some of the changes like REST API clean up etc. can be done by
>>adding
>>versioning others like migration to lifecycle framework etc. are bit more
>>involved. One important decision to be made is how to migrate to 1.0
>>release.
>>
>>Here are some of the options to migrate to new entity definitions in 1.0
>>(NOTE: REST api can be versioned and same end points can continue to work
>>albeit with newer definitions)
>>
>>*Approach 1*. Take a one time hit, call the release backward incompatible
>>and provide changes inside falcon to automatically migrate to newer
>>definitions on start up. We can support this migration code for a couple
>>of
>>releases and then later on remove it.
>>
>> pros:
>>- Clean and easy to code -  no if else etc. for supporting features in
>>multiple manners.
>>- Intuitive for users - multiple options for same purpose are confusing
>>for
>>the users.
>>- Easier to maintain - All bug fixes need to be done only in one code
>>flow
>>and not at many places.
>>
>>cons:
>>- involves migration - it can be automated by incorporating the migration
>>as part of falcon startup.
>>
>>
>>*Approach 2*. Support both old and new entity definitions.
>>pros
>>- users can work with both versions and migrate at their own pace
>>
>>cons
>>- Hard to maintain - Lot of code will need to be duplicated (validations
>>etc.) or branched (wf builders etc.) All bug fixes will need to be fixed
>>in
>>multiple places.
>>- Not scalable approach - The code will not scale easily if we decide to
>>support one more version.
>>- Manual migration - Users will have to migrate themselves to the new
>>entity definitions.
>>- Gotchas - What will happen if someone submits in newer version but
>>calls
>>update in older version?
>>
>>
>>I invite all of you to provide your thoughts on both the items. There
>>might
>>be more approaches or points to consider, suggestions are welcome.
>>
>>
>>Cheers
>>Ajay Yadava
>

RE: [DISCUSS] Apache Falcon 1.0 release

[Srikanth Sundarrajan <sr...@hotmail.com>]

Hi Balu,
    If we release frequently enough, then features would soon get into 1.0 line. New & meaty features and 1.0 can essentially be decoupled as 1.0 should be about stable and mature interfaces for users to work with in my view. Here is some background on some widely popular projects moving from 0.x to 1.0, should that help.

https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12329278&styleName=Text&projectId=12310843
https://github.com/apache/hadoop/blob/release-1.0.0/CHANGES.txt

Regards
Srikanth Sundarrajan

> Subject: Re: [DISCUSS] Apache Falcon 1.0 release
> From: bvellanki@hortonworks.com
> To: dev@falcon.apache.org
> Date: Wed, 6 Apr 2016 18:25:22 +0000
> 
> Hello Team, 
> 
> Here is my 2 cents,
> 
> Item 1 : "Apache Falcon 1.0² is a major milestone for the top level
> project and I sincerely think that it is important to have a good, easy to
> use UI as part of the release. Versioned APIs and Lifecycle framework are
> features we should definitely aim for in 1.0 release. If this pushes the
> timeline by a few weeks, I think the reward will be worth the delay.
> 
> Item 2 : I agree with Srikanth¹s suggestion and reasons to go with
> approach 2. 
> 
>  
> Thank you 
> Balu Vellanki 
> 
> 
> On 4/5/16, 11:43 AM, "Ajay Yadava" <aj...@apache.org> wrote:
> 
> >Hello everyone,
> >
> >For quite some time we have been discussing to make a 1.0 release and have
> >had several discussions in developer sync up around it. Taking this to
> >next
> >step, I propose next release line(after 0.10) of Apache Falcon to be 1.0
> >
> >
> >*Item 1 - Scope and Timelines*
> >Some of the items that are in works and I personally feel will be idle
> >candidate for 1.0 are - clean up our APIs(add a new version), introduce a
> >new shell for Falcon feed sla alerts, and move to the more powerful and
> >capable lifecycle framework for feeds among few.
> >
> >After lot of thought and discussions with several members, I propose to
> >not
> >aim for too many big features and a timeline of 2.5-3 months after the
> >0.10
> >release. This will ensure that critical fixes are not delayed and there is
> >only one active working line for code. We can add more features if other
> >community members are able to get them committed in time and our quality
> >team also feels comfortable.
> >
> >
> >*Item 2 - Migration Strategy*
> >While some of the changes like REST API clean up etc. can be done by
> >adding
> >versioning others like migration to lifecycle framework etc. are bit more
> >involved. One important decision to be made is how to migrate to 1.0
> >release.
> >
> >Here are some of the options to migrate to new entity definitions in 1.0
> >(NOTE: REST api can be versioned and same end points can continue to work
> >albeit with newer definitions)
> >
> >*Approach 1*. Take a one time hit, call the release backward incompatible
> >and provide changes inside falcon to automatically migrate to newer
> >definitions on start up. We can support this migration code for a couple
> >of
> >releases and then later on remove it.
> >
> > pros:
> >- Clean and easy to code -  no if else etc. for supporting features in
> >multiple manners.
> >- Intuitive for users - multiple options for same purpose are confusing
> >for
> >the users.
> >- Easier to maintain - All bug fixes need to be done only in one code flow
> >and not at many places.
> >
> >cons:
> >- involves migration - it can be automated by incorporating the migration
> >as part of falcon startup.
> >
> >
> >*Approach 2*. Support both old and new entity definitions.
> >pros
> >- users can work with both versions and migrate at their own pace
> >
> >cons
> >- Hard to maintain - Lot of code will need to be duplicated (validations
> >etc.) or branched (wf builders etc.) All bug fixes will need to be fixed
> >in
> >multiple places.
> >- Not scalable approach - The code will not scale easily if we decide to
> >support one more version.
> >- Manual migration - Users will have to migrate themselves to the new
> >entity definitions.
> >- Gotchas - What will happen if someone submits in newer version but calls
> >update in older version?
> >
> >
> >I invite all of you to provide your thoughts on both the items. There
> >might
> >be more approaches or points to consider, suggestions are welcome.
> >
> >
> >Cheers
> >Ajay Yadava
> 
 		 	   		  

Re: [DISCUSS] Apache Falcon 1.0 release

[Balu Vellanki Bala <bv...@hortonworks.com>]

Hello Team, 

Here is my 2 cents,

Item 1 : "Apache Falcon 1.0² is a major milestone for the top level
project and I sincerely think that it is important to have a good, easy to
use UI as part of the release. Versioned APIs and Lifecycle framework are
features we should definitely aim for in 1.0 release. If this pushes the
timeline by a few weeks, I think the reward will be worth the delay.

Item 2 : I agree with Srikanth¹s suggestion and reasons to go with
approach 2. 

 
Thank you 
Balu Vellanki 


On 4/5/16, 11:43 AM, "Ajay Yadava" <aj...@apache.org> wrote:

>Hello everyone,
>
>For quite some time we have been discussing to make a 1.0 release and have
>had several discussions in developer sync up around it. Taking this to
>next
>step, I propose next release line(after 0.10) of Apache Falcon to be 1.0
>
>
>*Item 1 - Scope and Timelines*
>Some of the items that are in works and I personally feel will be idle
>candidate for 1.0 are - clean up our APIs(add a new version), introduce a
>new shell for Falcon feed sla alerts, and move to the more powerful and
>capable lifecycle framework for feeds among few.
>
>After lot of thought and discussions with several members, I propose to
>not
>aim for too many big features and a timeline of 2.5-3 months after the
>0.10
>release. This will ensure that critical fixes are not delayed and there is
>only one active working line for code. We can add more features if other
>community members are able to get them committed in time and our quality
>team also feels comfortable.
>
>
>*Item 2 - Migration Strategy*
>While some of the changes like REST API clean up etc. can be done by
>adding
>versioning others like migration to lifecycle framework etc. are bit more
>involved. One important decision to be made is how to migrate to 1.0
>release.
>
>Here are some of the options to migrate to new entity definitions in 1.0
>(NOTE: REST api can be versioned and same end points can continue to work
>albeit with newer definitions)
>
>*Approach 1*. Take a one time hit, call the release backward incompatible
>and provide changes inside falcon to automatically migrate to newer
>definitions on start up. We can support this migration code for a couple
>of
>releases and then later on remove it.
>
> pros:
>- Clean and easy to code -  no if else etc. for supporting features in
>multiple manners.
>- Intuitive for users - multiple options for same purpose are confusing
>for
>the users.
>- Easier to maintain - All bug fixes need to be done only in one code flow
>and not at many places.
>
>cons:
>- involves migration - it can be automated by incorporating the migration
>as part of falcon startup.
>
>
>*Approach 2*. Support both old and new entity definitions.
>pros
>- users can work with both versions and migrate at their own pace
>
>cons
>- Hard to maintain - Lot of code will need to be duplicated (validations
>etc.) or branched (wf builders etc.) All bug fixes will need to be fixed
>in
>multiple places.
>- Not scalable approach - The code will not scale easily if we decide to
>support one more version.
>- Manual migration - Users will have to migrate themselves to the new
>entity definitions.
>- Gotchas - What will happen if someone submits in newer version but calls
>update in older version?
>
>
>I invite all of you to provide your thoughts on both the items. There
>might
>be more approaches or points to consider, suggestions are welcome.
>
>
>Cheers
>Ajay Yadava

Re: [DISCUSS] Apache Falcon 1.0 release

[pragya mittal <mi...@gmail.com>]

Hi All,

I would like to volunteer as a release manager for 1.0 release.

Thanks,
Pragya Mittal

On Wed, Apr 6, 2016 at 9:13 AM, Srikanth Sundarrajan <sr...@hotmail.com>
wrote:

> It is about time. We have been talking about 1.0 for nearly year and a
> half now and Thanks Ajay for initiating this discussion. I am hoping that
> this will push us closer towards 1.0.
>
> In general, we have been making more regular releases in the recent months
> and that has greatly helped us to get better and faster feedback on
> features that are built and also has allowed to be more iterative with our
> development. An attempt to get to 1.0 allows us to share with our user
> community a stable set of APIs that they can safely assume to not break
> across releases, the sooner we get there, the better it is for them.
>
> Going through the proposals Ajay has put forth, my reading is as follows
>
> Approach #1, auto converts entities from older version to newer and this
> auto convert will be withdrawn from the system after few version in 1.0 line
> Approach #2, auto converts entities, but retains the original entity
> definition as is for user submissions & modification operations and this is
> perpetual
>
> I find Approach #2 to be far more suitable for the following reasons:
>
> 1> The initial implementation required for both approaches are nearly
> identical
> 2> Users will be less confused when operating with the system
> 3> Approach #2 is essentially putting forth a model where there is
> semantic compatibility across version with syntactic differences in entity
> or api definitions.
>
> Should it help, I can do a small POC to allay any fears relating to
> complexity with approach #2.
>
> If there are more options in managing this, those should also be listed
> down for discussions.
>
> Regards
> Srikanth Sundarrajan
>
> > From: ajayyadava@apache.org
> > Date: Wed, 6 Apr 2016 00:13:04 +0530
> > Subject: [DISCUSS] Apache Falcon 1.0 release
> > To: dev@falcon.apache.org
> >
> > Hello everyone,
> >
> > For quite some time we have been discussing to make a 1.0 release and
> have
> > had several discussions in developer sync up around it. Taking this to
> next
> > step, I propose next release line(after 0.10) of Apache Falcon to be 1.0
> >
> >
> > *Item 1 - Scope and Timelines*
> > Some of the items that are in works and I personally feel will be idle
> > candidate for 1.0 are - clean up our APIs(add a new version), introduce a
> > new shell for Falcon feed sla alerts, and move to the more powerful and
> > capable lifecycle framework for feeds among few.
> >
> > After lot of thought and discussions with several members, I propose to
> not
> > aim for too many big features and a timeline of 2.5-3 months after the
> 0.10
> > release. This will ensure that critical fixes are not delayed and there
> is
> > only one active working line for code. We can add more features if other
> > community members are able to get them committed in time and our quality
> > team also feels comfortable.
> >
> >
> > *Item 2 - Migration Strategy*
> > While some of the changes like REST API clean up etc. can be done by
> adding
> > versioning others like migration to lifecycle framework etc. are bit more
> > involved. One important decision to be made is how to migrate to 1.0
> > release.
> >
> > Here are some of the options to migrate to new entity definitions in 1.0
> > (NOTE: REST api can be versioned and same end points can continue to work
> > albeit with newer definitions)
> >
> > *Approach 1*. Take a one time hit, call the release backward incompatible
> > and provide changes inside falcon to automatically migrate to newer
> > definitions on start up. We can support this migration code for a couple
> of
> > releases and then later on remove it.
> >
> >  pros:
> > - Clean and easy to code -  no if else etc. for supporting features in
> > multiple manners.
> > - Intuitive for users - multiple options for same purpose are confusing
> for
> > the users.
> > - Easier to maintain - All bug fixes need to be done only in one code
> flow
> > and not at many places.
> >
> > cons:
> > - involves migration - it can be automated by incorporating the migration
> > as part of falcon startup.
> >
> >
> > *Approach 2*. Support both old and new entity definitions.
> > pros
> > - users can work with both versions and migrate at their own pace
> >
> > cons
> > - Hard to maintain - Lot of code will need to be duplicated (validations
> > etc.) or branched (wf builders etc.) All bug fixes will need to be fixed
> in
> > multiple places.
> > - Not scalable approach - The code will not scale easily if we decide to
> > support one more version.
> > - Manual migration - Users will have to migrate themselves to the new
> > entity definitions.
> > - Gotchas - What will happen if someone submits in newer version but
> calls
> > update in older version?
> >
> >
> > I invite all of you to provide your thoughts on both the items. There
> might
> > be more approaches or points to consider, suggestions are welcome.
> >
> >
> > Cheers
> > Ajay Yadava
>
>

RE: [DISCUSS] Apache Falcon 1.0 release

[Srikanth Sundarrajan <sr...@hotmail.com>]

It is about time. We have been talking about 1.0 for nearly year and a half now and Thanks Ajay for initiating this discussion. I am hoping that this will push us closer towards 1.0. 

In general, we have been making more regular releases in the recent months and that has greatly helped us to get better and faster feedback on features that are built and also has allowed to be more iterative with our development. An attempt to get to 1.0 allows us to share with our user community a stable set of APIs that they can safely assume to not break across releases, the sooner we get there, the better it is for them.

Going through the proposals Ajay has put forth, my reading is as follows

Approach #1, auto converts entities from older version to newer and this auto convert will be withdrawn from the system after few version in 1.0 line
Approach #2, auto converts entities, but retains the original entity definition as is for user submissions & modification operations and this is perpetual 

I find Approach #2 to be far more suitable for the following reasons:

1> The initial implementation required for both approaches are nearly identical 
2> Users will be less confused when operating with the system
3> Approach #2 is essentially putting forth a model where there is semantic compatibility across version with syntactic differences in entity or api definitions.

Should it help, I can do a small POC to allay any fears relating to complexity with approach #2.

If there are more options in managing this, those should also be listed down for discussions.

Regards
Srikanth Sundarrajan

> From: ajayyadava@apache.org
> Date: Wed, 6 Apr 2016 00:13:04 +0530
> Subject: [DISCUSS] Apache Falcon 1.0 release
> To: dev@falcon.apache.org
> 
> Hello everyone,
> 
> For quite some time we have been discussing to make a 1.0 release and have
> had several discussions in developer sync up around it. Taking this to next
> step, I propose next release line(after 0.10) of Apache Falcon to be 1.0
> 
> 
> *Item 1 - Scope and Timelines*
> Some of the items that are in works and I personally feel will be idle
> candidate for 1.0 are - clean up our APIs(add a new version), introduce a
> new shell for Falcon feed sla alerts, and move to the more powerful and
> capable lifecycle framework for feeds among few.
> 
> After lot of thought and discussions with several members, I propose to not
> aim for too many big features and a timeline of 2.5-3 months after the 0.10
> release. This will ensure that critical fixes are not delayed and there is
> only one active working line for code. We can add more features if other
> community members are able to get them committed in time and our quality
> team also feels comfortable.
> 
> 
> *Item 2 - Migration Strategy*
> While some of the changes like REST API clean up etc. can be done by adding
> versioning others like migration to lifecycle framework etc. are bit more
> involved. One important decision to be made is how to migrate to 1.0
> release.
> 
> Here are some of the options to migrate to new entity definitions in 1.0
> (NOTE: REST api can be versioned and same end points can continue to work
> albeit with newer definitions)
> 
> *Approach 1*. Take a one time hit, call the release backward incompatible
> and provide changes inside falcon to automatically migrate to newer
> definitions on start up. We can support this migration code for a couple of
> releases and then later on remove it.
> 
>  pros:
> - Clean and easy to code -  no if else etc. for supporting features in
> multiple manners.
> - Intuitive for users - multiple options for same purpose are confusing for
> the users.
> - Easier to maintain - All bug fixes need to be done only in one code flow
> and not at many places.
> 
> cons:
> - involves migration - it can be automated by incorporating the migration
> as part of falcon startup.
> 
> 
> *Approach 2*. Support both old and new entity definitions.
> pros
> - users can work with both versions and migrate at their own pace
> 
> cons
> - Hard to maintain - Lot of code will need to be duplicated (validations
> etc.) or branched (wf builders etc.) All bug fixes will need to be fixed in
> multiple places.
> - Not scalable approach - The code will not scale easily if we decide to
> support one more version.
> - Manual migration - Users will have to migrate themselves to the new
> entity definitions.
> - Gotchas - What will happen if someone submits in newer version but calls
> update in older version?
> 
> 
> I invite all of you to provide your thoughts on both the items. There might
> be more approaches or points to consider, suggestions are welcome.
> 
> 
> Cheers
> Ajay Yadava