falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Balu Vellanki Bala <bvella...@hortonworks.com>
Subject Re: [DISCUSS] Apache Falcon 1.0 release
Date Wed, 06 Apr 2016 18:25:22 GMT
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 have
>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 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
>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 flow
>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 calls
>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