Hi Ramesh, Sorry I did not see the critical part. In this case I completely agree. Fixing critical issues for the core library should be part of our guidelines. For "major" issues I am not entirely sure since this is the default tag for new created issues and few change this. So there either needs to be a reclassification by us or a discussion once we approach the release which of these issues we can push to a later release IHMO. Making JPA a separate project is my hope for the V4 part of Olingo. I think changing the V2 part would be too much effort at this point in time :) Also I completely agree with the informal releases for feedback. How does the Teiid community handle this? By providing a maven build artifact with a "beta" in its name or by just pointing users to the current SNAPSHOT after a certain amount of time?
Best Regards, Christian -----Original Message----- From: Ramesh Reddy [mailto:[email protected]] Sent: Mittwoch, 21. Oktober 2015 16:00 To: [email protected] Subject: Re: [DISCUSS] Future Release cycle of the Olingo V4 library On Point 2, I said "crtical/Major" tag line, I am saying if something is deemed as critical and major then we should make an effort to fix those. May be we should limit this restriction to "core" framework, not JPA or other extensions. IMO, JPA needs to be its own sub-project based on some stable version Olingo, not core part of Olingo. But that not how it is set up right now, and completely separate topic ;) Down porting is time consuming, until we get to very stable state, yes I agree it is better to recommend to upgrade to newer versions, that will save time. Yes, ALPHA, BETA should informal releases (no voting) that are there to get feed back on features before final release, where as final does require voting. Ramesh.. ----- Original Message ----- > Hi Ramesh, > > I really like having a clear timeline. Around 3 months sounds reasonable to > me as well. > > Point 1 sounds good and should ensure that the community is on a clear basis > what to develop. I like this a lot. > > Point 2 worries me though. I completely agree with never downporting fixes if > there is a clear workaround. I would even go as far as recommending users to > upgrade to a newer version to receive a Bugfix if possible. This ensures > development speed from our side. > Yet personally I think that fixing all bugs is not feasible with the time I > have to contribute to the project. For example the V4 client code and the V2 > JPA processor have been contributed to Olingo and I am not as knowledgeable > in these domains as I am with the server part. So I would not want to delay > a release simply because there are open client bugs that I can`t fix either > because of time constraints or knowledge issues. So I would not make open > bugs a blocker for a release. I completely agree with fixing as many bugs as > possible before a release though. > Also I hope that bugs that are a "pain" for the community will result in more > contributions for fixes. This is something we are lacking right now IMHO. > > Another point I am not sure about is the beta release. In my opinion this is > the current SNAPSHOT version. I would not perform a real beta release and > publish it through all channels because I think this is a process overhead > with how the release process currently goes. This includes votings on the > mailing list and the verification of all release artifacts. I could think of > an informal beta release where we simply change the mvn version number for a > single deploy to give users a stable version to use. Or after 1,5 months we > simply drop a mail to the user list to encourage users to try the current > snapshot version. > > WDYT? > > Best Regards, > Christian > > -----Original Message----- > From: Ramesh Reddy [mailto:[email protected]] > Sent: Freitag, 9. Oktober 2015 23:05 > To: [email protected] > Subject: Re: [DISCUSS] Future Release cycle of the Olingo V4 library > > Christian, > > Thank you for reaching out to the broader community, I really appreciate it. > In my experience #3 works as good policy for us in Teiid community. We > release about every ~3 months (+/-2Wks). However, there are two rules we > follow > > 1) At the beginning of the cycle, (or more towards the end of last cycle) we > reach out to the community and look at current JIRAs and figure out what are > the couple major features/enhancements we want to get done. These we label > as "driving" factors for the release. These are must have features. Note > that these could be computed from # votes received from community etc. > > 2) Fix ANY and ALL the bugs found in previous and current releases. Never > "push" a "critical/major" bugs into another release unless there is clear > workaround or alternative. Community really appreciates timely fixes of > known bugs. > > Then there may be internal requests team need to honor <wink>, and what > contributors like me would want to contribute for supporting our community > <wink>. And then there are best effort enhancements, that we could push to > next/future releases if they did not get done in time. > > At the beginning, we can set the target date for the release, and do a "beta" > releases, after first month/month and half, depending upon the feature > completions. > > development = 0 - 1 1/2 months > beta = 1 1/2 - 2 1/2 months > CR/Release = 2 1/2 - 3 months > > During this time, if you have the cadence, you can also do bug fix releases > on the previous releases, depending upon the need. > > WDYT? > > Ramesh.. > > > ----- Original Message ----- > > Hi all, > > > > Since we now have the first stable release with our 4.0.0 version I > > would like to start a discussion about the future release cycle of the > > V4 library. With the V2 library there have not been many people from > > the open source world involved so the Olingo members have been > > releasing if they thought it was a good idea. Communication about this > > was mostly done privately until the vote mail was send to the dev > > list. Even with the V4 beta releases there has not been a really clear > > path of what we hoped to get into the releases and when to release > > them. > > > > Since there are now more contributors I would like the Olingo > > community to get to a consensus about how we as an Apache project want > > to handle this in the future. > > > > 1. Should we define a feature set and log it inside JIRA. Then once > > this set is implemented a release is done. > > 2. Should we define a time cycle e.g. 1-3 months and provide releases > > even if some features are not ready. > > 3. A combination I could not yet think of > > > > WDYT? > > > > Best Regards, > > Christian > > >
