hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: [NOTICE] Branching for 1.0
Date Fri, 04 Jul 2014 16:51:50 GMT
On Fri, Jul 4, 2014 at 1:29 AM, Enis Söztutar <enis@apache.org> wrote:
>
>
> 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.
>
>
That might work if we are careful.

Problem is bulk edit of JIRA resolved version.  JIRAs may have been marked
with multiple versions in the resolved versions box. The bulk edit
overwrites whatever was in the resolve version with the new bulk edit
version. I overwrote a bunch of careful JIRA edits made by Lars bulk
editing 0.96.x versions.

Beware bulk editing.

St.Ack



> 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