Either way works. Personally I'd remove the 1.0.0 tag since it adds confusion. I guess if you want to distinguish between 0.99 and 1.0 we'd need it, but when would we want that? (I.e. when do we want a 0.99 release with a known blocker/critical issue in it?)
-- Lars ________________________________ From: Enis Söztutar <[email protected]> To: "[email protected]" <[email protected]>; lars hofhansl <[email protected]> Sent: Friday, July 4, 2014 1:29 AM Subject: Re: [NOTICE] Branching for 1.0 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 <[email protected]> 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 <[email protected]> > To: [email protected] > 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 <[email protected]> > 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 <[email protected]> wrote: > > > > > On Tue, Jul 1, 2014 at 4:01 PM, Enis Söztutar <[email protected]> > > 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 <[email protected]> > > > 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 <[email protected]> > > 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 < > > [email protected]> > > > > > > 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 < > > > [email protected]> > > > > > > > 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 < > > > [email protected] > > > > > > > > > > > > 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) > > >
