falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ying Zheng <yzh...@hortonworks.com>
Subject Re: [DISCUSS] Apache Falcon 1.0 release
Date Thu, 07 Apr 2016 00:23:32 GMT
+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 :)


On 4/6/16, 11:25 AM, "Balu Vellanki Bala" <bvellanki@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" <ajayyadava@apache.org> wrote:
>>Hello everyone,
>>For quite some time we have been discussing to make a 1.0 release and
>>had several discussions in developer sync up around it. Taking this to
>>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
>>aim for too many big features and a timeline of 2.5-3 months after the
>>release. This will ensure that critical fixes are not delayed and there
>>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
>>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
>>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
>>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
>>the users.
>>- Easier to maintain - All bug fixes need to be done only in one code
>>and not at many places.
>>- involves migration - it can be automated by incorporating the migration
>>as part of falcon startup.
>>*Approach 2*. Support both old and new entity definitions.
>>- users can work with both versions and migrate at their own pace
>>- 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
>>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
>>update in older version?
>>I invite all of you to provide your thoughts on both the items. There
>>be more approaches or points to consider, suggestions are welcome.
>>Ajay Yadava

View raw message