Sounds good to me, I like the idea of queueing up PRs for the N+1th release when we start the Nth release.
On Wed, May 27, 2015 at 4:16 PM, Ryan Blue <[email protected]> wrote: > Thanks, Alex! > > I agree that we want to have regular releases and to do it be careful > about what gets put into master. One thing to keep in mind is that keeping > up on reviews and bug fixes will definitely help here. > > We have quite a few bug reports, most with contributed fixes, that are > still waiting to get merged. Now that we want to release, I think those are > blockers... if bugs don't block a release, then we'll just get further and > further behind. > > We also have a lot of contributions that need to be reviewed and merged. > Int64 delta encoding, for instance, is a fantastic addition from someone > that is pretty attentive. I want to make sure that makes the next release. > > So in addition to what you propose, I think we should: > > 1. Consider serious bugs blockers for any release (within reason). This is > to motivate us to keep up on the fixes. > > 2. Identify contributions that are close and make them blockers for the > subsequent release (again, within reason). That way we force ourselves to > keep up with contributions as well. > > Does that sound reasonable? I've added what I think should be considered > blockers for this release. Most of them have fixes already in PRs. > > rb > > > On 05/27/2015 03:49 PM, Alex Levenson wrote: > >> Hello, >> >> I'd like to propose that we publish a minor release of parquet, eg version >> 1.8.0 >> >> I think this also points out that we could use some policy / guiding >> principles around when and how to do minor releases (ideally we can do >> them >> fairly often). >> >> I think a good policy would be to choose a point in time to "begin" a >> release, at which point the only pending PRs that block the release are >> bug >> fixes for issues known to be in master already. Once those blockers are >> merged, the release goes out, and we can start merging new features again. >> The motivation for this is to prevent long releases blocked on many >> pending >> features. If we can release early and often, we won't feel a need to get a >> PR into any one particular release. >> >> We can either do this by being careful about what goes into master (aim >> for >> master always being releasable), or we can make release branches and only >> merge bug fixes into release branches. I think maintaining release >> branches >> w/ backports can get fairly difficult so I'd probably lean towards not >> going that direction. >> >> So that said, what do you all think? >> Also, does anyone have any bug fixes that needs to go into master before a >> 1.8.0 release? >> >> If so please add it to: >> https://issues.apache.org/jira/browse/PARQUET-292 >> >> Thanks! >> Alex >> > > > -- > Ryan Blue > Software Engineer > Cloudera, Inc. > -- Alex Levenson @THISWILLWORK
