Yes, we would to reclassify (as for user entering the JIRA it is always a blocker ;)) . Yes, JPA I am talking about V4, not V2.
In Teiid, yes we provide jars/kits available through maven repo for alpha/beta with alpha/beta tags. The master branch is always working on next SNAPSHOT. Ramesh.. ----- Original Message ----- > 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 > > > > > >
