👍 On Tue, Aug 15, 2017 at 8:39 AM, Sijie Guo <guosi...@gmail.com> wrote:
> Added a page on website about the release schedule : > http://bookkeeper.apache.org/community/releases > > Marked the BP-13 as accepted, since there is no objections to this. Let's > try out this release plan in 4.6.0. > > - Sijie > > On Mon, Aug 14, 2017 at 1:59 AM, Enrico Olivelli <eolive...@gmail.com> > wrote: > > > Let's do it. > > Jia if you want to manage ir for me it us ok. I would try for 4.7 or > 4.5.1 > > > > Enrico > > > > Il lun 14 ago 2017, 08:50 Sijie Guo <guosi...@gmail.com> ha scritto: > > > > > I updated the wiki page to reflect what Matteo suggested - 3 months per > > > release and 4 releases per year. > > > > > > so the release schedule will be: > > > > > > - 4.6.0 : August 2017 - November 2017 > > > - 4.7.0 : November 2017 - February 2018 > > > - 4.8.0 : February 2018 - May 2018 > > > - 4.9.0 : May 2018 - August 2018 > > > > > > If there is no objections on adopting time based release plan, let's > try > > > this out for 4.6.0. > > > > > > - Sijie > > > > > > On Fri, Aug 11, 2017 at 11:28 AM, Sijie Guo <guosi...@gmail.com> > wrote: > > > > > > > Matteo, > > > > > > > > Thank you for your comments. Make sense to me. Will update the BP if > > > there > > > > is no other suggestions. > > > > > > > > Sijie > > > > > > > > > > > > On Aug 11, 2017 9:33 AM, "Matteo Merli" <matteo.me...@gmail.com> > > wrote: > > > > > > > > I would suggest to do quarterly releases (eg: every 3 months), since > > that > > > > seems to me a good tradeoff ratio between planning and agility of > > > shipping > > > > new features/improvements. > > > > > > > > Matteo > > > > > > > > On Fri, Aug 11, 2017 at 4:36 AM Enrico Olivelli <eolive...@gmail.com > > > > > > wrote: > > > > > > > > > Il ven 11 ago 2017, 13:10 Sijie Guo <guosi...@gmail.com> ha > scritto: > > > > > > > > > > > Folks, please take a look at this. We need to decide the schedule > > for > > > > > > 4.6.0. > > > > > > > > > > > > > > > > Maybe we can take 4.3 clients as compatible baseline for 4.6. > > > > > > > > > > What is the next step? > > > > > Shiuld you call a vote ? > > > > > > > > > > Enrico > > > > > > > > > > > > > > > > - Sijie > > > > > > > > > > > > On Mon, Aug 7, 2017 at 6:59 PM, Sijie Guo <guosi...@gmail.com> > > > wrote: > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > First thanks everyone who contributed to 4.5.0 in the past > year, > > > and > > > > > > > especially thanks JV for spending time doing the release. The > > first > > > > > > release > > > > > > > candidate of 4.5.0 is finally out of review now. We are almost > > > there. > > > > > > > > > > > > > > We eventually merge the major features from 3 main folked > > branches > > > > > > > (Salesforce, Twitter and Yahoo), so that we can converge to one > > > main > > > > > open > > > > > > > source branch across different organizations. We added a lot of > > > > > features, > > > > > > > bug fixes and improvements. We moved to github to make > > contribution > > > > > > easier > > > > > > > and friendly and we have new website with more documentation. > > There > > > > are > > > > > > > tons of works we did very well in 4.5.0. > > > > > > > > > > > > > > However, I think the release has taken too long to complete. It > > > > causes > > > > > a > > > > > > > lot of inconsistencies between code, configuration and > > > documentation. > > > > > > This > > > > > > > causes most of the contributions were spent on improving > > > > documentation > > > > > at > > > > > > > the end of the release. And also people can't really follow > > what's > > > > > > > happening in a long-cycle release and they eventually left. > > > > > > > > > > > > > > I am thinking of changing the release plan/schedule to a more > > > > > time-based > > > > > > > mechanism what other projects (like Kafka, Flink) are doing: > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/Time+Based > > > > +Release+Plan > > > > > > > Some of the benefits are documented in their wikis (also copied > > > them > > > > in > > > > > > > the email for easy to read). > > > > > > > > > > > > > > Any thoughts? Shall we try to adopt this method? > > > > > > > > > > > > > > > > > > > > > 1. > > > > > > > > > > > > > > A quicker feedback cycle and users can benefit from features > > > > shipped > > > > > > > quicker > > > > > > > 2. > > > > > > > > > > > > > > Predictability for contributors and users: > > > > > > > 1. > > > > > > > > > > > > > > Developers and reviewers can decide in advance what > release > > > > they > > > > > > > are aiming for with specific features. > > > > > > > 2. > > > > > > > > > > > > > > If a feature misses a release we have a good idea of when > > it > > > > will > > > > > > > show up. > > > > > > > 3. > > > > > > > > > > > > > > Users know when to expect their features > > > > > > > 3. > > > > > > > > > > > > > > Transparency - There will be a published cut-off date (AKA > > > feature > > > > > > > freeze) for the release and people will know about it in > > > advance. > > > > > > Hopefully > > > > > > > this will remove the contention around which features make > it. > > > > > > > 4. > > > > > > > > > > > > > > Quality - we've seen issues pop up in release candidates due > > to > > > > > > > last-minute features that didn't have proper time to bake > in. > > > More > > > > > > time > > > > > > > between feature freeze and release will let us test more, > > > document > > > > > > more and > > > > > > > resolve more issues. > > > > > > > > > > > > > > > > > > > > > - Sijie > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > -- Enrico Olivelli > > > > > > > > > -- > > > > Matteo Merli > > > > <mme...@apache.org> > > > > > > > > > > > > > > > > > -- > > > > > > -- Enrico Olivelli > > >
