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 >
