hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <e...@apache.org>
Subject Re: [NOTICE] Branching for 1.0
Date Fri, 04 Jul 2014 08:29:24 GMT
We only had 4 issues with fixVersion = 1.0.0 and status = resolved. I
manually removed the labels from those.

https://issues.apache.org/jira/browse/HBASE-11449?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20HBASE%20and%20status%20%3D%20resolved

Keeping the version label helps us tag it as a blocker / critical to the
1.0 release, no? If it is confusing I can remove it.

Committers, please do not tag resolved issues with fixVersion = 1.0.0. The
next release from the branch-1 branch is 0.99.0.

Enis



On Thu, Jul 3, 2014 at 9:09 AM, lars hofhansl <larsh@apache.org> wrote:

> We have to get rid of the 0.99 or the 1.0.0 tag since they designate the
> same branch.
> Since we mostly used 0.99, we should move all jiras targeted to 1.0.0 to
> 0.99 and delete the current 1.0.0 version. 0.99 can later be renamed to
> 1.0.0.
> (from painful experience... Don't do that retargeting in bulk, since jira
> will remove all other fix versions)
>
>
> -- Lars
>
>
>
> ________________________________
>  From: Anoop John <anoop.hbase@gmail.com>
> To: dev@hbase.apache.org
> Sent: Tuesday, July 1, 2014 5:30 PM
> Subject: Re: [NOTICE] Branching for 1.0
>
>
> >Starting today, if a patch goes to 0.98 branch, the Fix Version/s field
> should include 0.98, 0.99 and 2.0.0, right ?
>
>
> Ted asked this..
>
> Same from me
>
> Fix version to be 0.99  or 1.0.0?
>
> -Anoop-
>
>
>
>
> On Wed, Jul 2, 2014 at 5:31 AM, Andrew Purtell <apurtell@apache.org>
> wrote:
>
> > I think as 0.98 RM if the consensus is no it shouldn't go into 1.0 I'd
> have
> > to cancel the pending 0.98 RC and revert the change. If we take too long
> to
> > reach consensus about 1.0 and the 0.98 RC vote carries, that would force
> > inclusion into 1.0. Interesting possibilities. But we do have two
> separate
> > branches and two separate release trains - at least - so we'll have to
> > figure it out.
> >
> >
> > On Tue, Jul 1, 2014 at 4:50 PM, Nick Dimiduk <ndimiduk@gmail.com> wrote:
> >
> > > On Tue, Jul 1, 2014 at 4:01 PM, Enis Söztutar <enis.soz@gmail.com>
> > wrote:
> > >
> > > > One other thing we can do is that we can commit the patch to 0.98 if
> > you
> > > > +1, do the RC, but hold on for committing to 1.0. During the RC vote
> > > > timeframe, we can then reach a consensus for whether the patch should
> > go
> > > > into both branches.
> > > >
> > >
> > > It would be a shame to loose track of patches because of this
> additional
> > > administrative step happening asynchronously from initial push of the
> > > commit.
> > >
> > > On Tue, Jul 1, 2014 at 3:34 PM, Andrew Purtell <apurtell@apache.org>
> > > wrote:
> > > >
> > > > > I agree just about everything related to HBASE-10856 is something
> > that
> > > > > merits discussion and consensus.
> > > > >
> > > > > > My main goal for branch-1 is to limit the exposure for unrelated
> > > > changes
> > > > > in the branch for a more stable release
> > > > >
> > > > > This is a goal shared by 0.98 so that's no issue at all.
> > > > >
> > > > > What we should sort out is coordinating RTC on multiple active
> > > branches.
> > > > > For example, it's not possible for me to commit to rolling a 0.98
> RC
> > > on a
> > > > > particular day if we have a blocker that needs to go through 1.0
> > first,
> > > > > since it is not clear for any given commit when or if it will be
> > acked
> > > > for
> > > > > 1.0.
> > > > >
> > > > >
> > > > > On Tue, Jul 1, 2014 at 3:29 PM, Enis Söztutar <enis@apache.org>
> > wrote:
> > > > >
> > > > > > Agreed that for every feature including security, we should
be
> > > careful
> > > > to
> > > > > > not create a gap in terms of support (release x supporting,
> release
> > > x+1
> > > > > not
> > > > > > supporting, release x+2 supporting etc).
> > > > > >
> > > > > > My main goal for branch-1 is to limit the exposure for unrelated
> > > > changes
> > > > > in
> > > > > > the branch for a more stable release. If we think that we need
to
> > > > > > fix/improve some things for 1.0 and 0.98.x, it will be ok to
> > commit.
> > > > Some
> > > > > > of the items linked under
> > > > > > https://issues.apache.org/jira/browse/HBASE-10856
> > > > > > imply big changes, but it would be ok to commit those to have
a
> > clear
> > > > > > story.
> > > > > >
> > > > > > I think we can decide on a per-issue/feature basis.
> > > > > > Enis
> > > > > >
> > > > > >
> > > > > > On Tue, Jul 1, 2014 at 3:16 PM, Andrew Purtell <
> > apurtell@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Now that I think about it more, actually every commit,
since I
> > > don't
> > > > > > think
> > > > > > > we want a situation where something goes into master and
0.98,
> > but
> > > > not
> > > > > > 1.0.
> > > > > > > We should discuss how to handle this.
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Jul 1, 2014 at 3:10 PM, Andrew Purtell <
> > > apurtell@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I'm curious what will be the policy for security commits?
I
> > plan
> > > to
> > > > > > take
> > > > > > > > all security changes into 0.98. If we have commits
to master
> > and
> > > > 0.98
> > > > > > > that
> > > > > > > > will result in a serious feature / functionality
> discontinuity.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Jun 30, 2014 at 8:56 PM, Enis Söztutar <
> > > enis.soz@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >> I've pushed the branch, named branch-1:
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=shortlog;h=refs/heads/branch-1
> > > > > > > >>
> > > > > > > >> Please do not commit new features to branch-1
without
> pinging
> > > the
> > > > RM
> > > > > > > (for
> > > > > > > >> 1.0 it is me). Bug fixes, and trivial commits
can always go
> > in.
> > > > > > > >>
> > > > > > > >> That branch still has 0.99.0-SNAPSHOT as the version
number,
> > > since
> > > > > > next
> > > > > > > >> expected release from that is 0.99.0. Jenkins
build for this
> > > > branch
> > > > > is
> > > > > > > >> setup at https://builds.apache.org/view/All/job/HBase-1.0/.
> > It
> > > > > builds
> > > > > > > >> with
> > > > > > > >> latest jdk7. I'll try to stabilize the unit tests
for the
> > first
> > > > RC.
> > > > > > > >>
> > > > > > > >> I've changed the master version as well. It now
builds with
> > > > > > > >> 2.0.0-SNAPSHOT.
> > > > > > > >> Exciting!
> > > > > > > >>
> > > > > > > >> Enis
> > > > > > > >>
> > > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > >
> > > > >    - Andy
> > > > >
> > > > > Problems worthy of attack prove their worth by hitting back. - Piet
> > > Hein
> > > > > (via Tom White)
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message