Il gio 10 ago 2017, 10:09 Sijie Guo <guosi...@gmail.com> ha scritto: > yes, it is end-of-life. For example, currently we kept all the release > versions since 2011? but I believe there is no one still running releases > like 4.0.* and 4.1.*, even 4.2*.
Idea: shall we do some kind of survey anout the versions in use? I do not have much experience or knowledge, I am following BK since 4.3, but my feeling is that there is no 4.3 BookKeeper running in production Enrico We definitely need to clean up those old > releases and mark them as EOL (no more support from the community). If we > decide to go with time based releases, we will have more releases, which > make the EOL more obvious, otherwise it is so hard to keep backward > compatibility. > > On Wed, Aug 9, 2017 at 2:20 AM, Jia Zhai <zhaiji...@gmail.com> wrote: > > > Thanks for this. It looks clear in the link. We could discuss the blue > > items in the meeting. > > BTW, what is EOL stand for? End of Life? > > > > On Wed, Aug 9, 2017 at 2:45 PM, Sijie Guo <guosi...@gmail.com> wrote: > > > > > I drafted a BP to adopt the Kafka one. I also highlights the content > that > > > might require discussions in blue in the wiki page: > > > https://cwiki.apache.org/confluence/display/BOOKKEEPER/ > > > BP-13+-+Time+Based+Release+Plan > > > > > > Also I listed following points that require discussion for people to > > check > > > them easier: > > > > > > > > > - Length of a release: 4 months > > > - How does release cycle looks like? > > > > > > - A month before release date: Release manager cuts the branch and > starts > > > prepare the release notes including the features. > > > > > > - Leave another week for minor features to get in. > > > > > > - Last two weeks before release: Announce code freeze and start rolling > > the > > > RCs. > > > > > > - Apply scope: > > > > > > - Applied to major/minor feature releases. Bugfix releases will be done > > > based on the severity of bugs. > > > > > > - If a feature is too large to span over releases? > > > > > > - 1) break the feature into small pieces. > > > > > > - 2) use feature branches > > > > > > - What are the gaps to focus on? > > > > > > - Test coverage with check ins. > > > > > > - Documentation coverage with check ins. > > > > > > - Compatibility testing. > > > > > > - What is our EOL policy? > > > > > > - rolling upgrade can be done from each release in past year (last 3 > > > releases) to latest release > > > > > > - Schedule for next 4 releases: > > > > > > - August 2017 - November 2017 > > > > > > - November 2017 - February 2018 > > > > > > - February 2018 - May 2018 > > > > > > - May 2018 - August 2018 > > > > > > > > > Any thoughts? > > > > > > - Sijie > > > > > > > > > > > > On Tue, Aug 8, 2017 at 1:00 AM, Enrico Olivelli <eolive...@gmail.com> > > > wrote: > > > > > > > It would be great. > > > > Thank you > > > > Enrico > > > > > > > > Il mar 8 ago 2017, 09:24 Jia Zhai <zhaiji...@gmail.com> ha scritto: > > > > > > > > > +1 to adopt it. All the benefits seems reasonable. > > > > > > > > > > On Tue, Aug 8, 2017 at 9:59 AM, 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 > > > > > > > > > > -- -- Enrico Olivelli
