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*. 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 > > > > > >
