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 <[email protected]> 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: [email protected] > > Date: Wed, 6 Apr 2016 00:13:04 +0530 > > Subject: [DISCUSS] Apache Falcon 1.0 release > > To: [email protected] > > > > 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 > >
