Minor Release

[Alex Levenson <al...@twitter.com.INVALID>]

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

-- 
Alex Levenson
@THISWILLWORK

Re: Minor Release

[Julien Le Dem <ju...@twitter.com.INVALID>]

+1 on releasing often.


On Wed, May 27, 2015 at 4:21 PM, Alex Levenson <
alexlevenson@twitter.com.invalid> 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 <bl...@cloudera.com> 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
>

Re: Minor Release

[Alex Levenson <al...@twitter.com.INVALID>]

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 <bl...@cloudera.com> 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

Re: Minor Release

[Ryan Blue <bl...@cloudera.com>]

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.