Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Marking fix version

Copy link to this message
Re: Marking fix version
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 <[EMAIL PROTECTED]>
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
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.


// Jonathan Hsieh (shay)
// Software Engineer, Cloudera