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
