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.
