+1 on releasing often.
On Wed, May 27, 2015 at 4:21 PM, Alex Levenson < [email protected]> wrote: > 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 >
