hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <la...@apache.org>
Subject Re: Marking fix version
Date Thu, 04 Apr 2013 19:04:34 GMT
Not necessarily. 0.95 is special in that it is a known "experimental" version to play with.




________________________________
 From: Nick Dimiduk <ndimiduk@gmail.com>
To: dev@hbase.apache.org; lars hofhansl <larsh@apache.org> 
Sent: Thursday, April 4, 2013 11:55 AM
Subject: Re: Marking fix version
 
By this logic, 0.98 tag should be renamed to 0.97, yes?

On Thu, Apr 4, 2013 at 10:33 AM, lars hofhansl <larsh@apache.org> wrote:

> Yes, I think we should remove the 0.96 tag. Stack said the other day that
> he should have just renamed 0.96 to 0.95 rather than moving all the issues.
>
> The rest is already what I have been doing for issues I am committing (so
> +1 :) ), but I did notice that not all issues are tagged correctly.
>
>
> -- Lars
>
>
>
> ________________________________
>  From: Jonathan Hsieh <jon@cloudera.com>
> To: dev@hbase.apache.org; lars hofhansl <larsh@apache.org>
> Sent: Thursday, April 4, 2013 10:15 AM
> Subject: Re: Marking fix version
>
>
> The argument for excluding the 0.96 tag makes sense.  Can we agree to do
> this:
>
>
> Commit only to trunk: Mark with 0.98
> Commit to 0.95 and trunk : Mark with 0.98, and 0.95.x
> Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.95.x, and 0.94.x
>
> Commit to 89-fb: Mark with 89-fb.
> Commit site fixes: no version
>
> Should we remove 0.96 tag for now until the branch appears again?
>
> Thanks,
> Jon.
>
> On Thu, Apr 4, 2013 at 10:10 AM, lars hofhansl <larsh@apache.org> wrote:
>
> Thank Jon,
> >
> >I do not think we have to include anticipated future branches in the tags.
> >The release notes are not accumulative but list changes made for each
> release.
> >
> >So if something is in 0.95.x a 0.96 tag neither needed nor wanted (IMHO)
> until we actually have a *parallel* 0.96 branch.
> >
> >That is why all 0.95+trunk changes *have* to be tagged with 0.98 as well,
> because at this point the two branches are in parallel. Actually we should
> go through and make that so in jira.
> >
> >That means the 0.96 tag is not needed right now (and in fact will make
> just confusing, because at the time we do release 0.96 we'll see the same
> issue in the release notes twice)
> >
> >-- Lars
> >
> >
> >
> >________________________________
> > From: Jonathan Hsieh <jon@cloudera.com>
> >To: dev@hbase.apache.org
> >Sent: Thursday, April 4, 2013 8:40 AM
> >Subject: Marking fix version
> >
> >
> >Hey all,
> >
> >I just wanted to make sure we are on the same page here when we committing
> >code and that we are consistent when marking fix version in the jira.  Its
> >pretty important that we get this right because our release notes are
> >generated from these as of 0.94.
> >
> >Here's what I'm doing and suggesting
> >
> >Commit only to trunk: Mark with 0.98
> >Commit to 0.95 and trunk : Mark with 0.98, 0.96, and 0.95.x
> >Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.96, 0.95.x, and
> >0.94.x
> >Commit to 89-fb: Mark with 89-fb.
> >Commit site fixes: no version
> >
> >My understanding is that 0.96 will be a branch off of 0.95 -- so any fix
> to
> >0.95 is a fix to 0.96 until 0.96 branches.
> >
> >Thanks,
> >Jon.
> >
> >--
> >// Jonathan Hsieh (shay)
> >// Software Engineer, Cloudera
> >// jon@cloudera.com
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
>
> // jon@cloudera.com
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message