+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" <[email protected]> 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" <[email protected]> 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 >
