falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pragya mittal <mittal.pragy...@gmail.com>
Subject Re: [DISCUSS] Apache Falcon 1.0 release
Date Wed, 06 Apr 2016 12:17:53 GMT
Hi All,

I would like to volunteer as a release manager for 1.0 release.

Thanks,
Pragya Mittal

On Wed, Apr 6, 2016 at 9:13 AM, Srikanth Sundarrajan <sriksun@hotmail.com>
wrote:

> It is about time. We have been talking about 1.0 for nearly year and a
> half now and Thanks Ajay for initiating this discussion. I am hoping that
> this will push us closer towards 1.0.
>
> In general, we have been making more regular releases in the recent months
> and that has greatly helped us to get better and faster feedback on
> features that are built and also has allowed to be more iterative with our
> development. An attempt to get to 1.0 allows us to share with our user
> community a stable set of APIs that they can safely assume to not break
> across releases, the sooner we get there, the better it is for them.
>
> Going through the proposals Ajay has put forth, my reading is as follows
>
> Approach #1, auto converts entities from older version to newer and this
> auto convert will be withdrawn from the system after few version in 1.0 line
> Approach #2, auto converts entities, but retains the original entity
> definition as is for user submissions & modification operations and this is
> perpetual
>
> I find Approach #2 to be far more suitable for the following reasons:
>
> 1> The initial implementation required for both approaches are nearly
> identical
> 2> Users will be less confused when operating with the system
> 3> Approach #2 is essentially putting forth a model where there is
> semantic compatibility across version with syntactic differences in entity
> or api definitions.
>
> Should it help, I can do a small POC to allay any fears relating to
> complexity with approach #2.
>
> If there are more options in managing this, those should also be listed
> down for discussions.
>
> Regards
> Srikanth Sundarrajan
>
> > From: ajayyadava@apache.org
> > Date: Wed, 6 Apr 2016 00:13:04 +0530
> > Subject: [DISCUSS] Apache Falcon 1.0 release
> > To: dev@falcon.apache.org
> >
> > 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