falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srikanth Sundarrajan <srik...@hotmail.com>
Subject RE: [DISCUSS] Apache Falcon 1.0 release
Date Thu, 07 Apr 2016 03:34:29 GMT
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" <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
> >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
> 
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message