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 >> >> >> >> On Mon, Jun 30, 2014 at 2:34 PM, Kevin O'dell <[email protected]> >> wrote: >> >> > HURRAY! >> > >> > >> > On Mon, Jun 30, 2014 at 5:30 PM, Enis Söztutar <[email protected]> wrote: >> > >> > > Devs, >> > > >> > > I will be creating the branch named "branch-1" in a couple of hours >> (see >> > > previous threads [1],[2],[3]. >> > > >> > > We have agreed to go with the branching structure that will look like >> > this: >> > > >> > > master (2.0-SNAPSHOT) >> > > | >> > > | branch-1 (1.1-SNAPSHOT) >> > > | | >> > > | | branch-1.0 (1.0.1-SNAPSHOT) >> > > | | | >> > > | | x (1.0.0) >> > > | | | >> > > | |/ >> > > | x (0.99.1) >> > > | | >> > > | x (0.99.0) >> > > | | >> > > |/ >> > > >> > > >> > > This structure will give us flexibility to have both multiple active >> 1.x >> > > releases, and have 2.0 patches to be committable. And also we can use >> > > semantic versioning for our releases from now on [4]. >> > > >> > > For now, the repo will look like as below, and before 1.0.0, >> branch-1.0 >> > > will be forked from branch-1 and the tree will more like as above. >> > > >> > > >> > > master (2.0-SNAPSHOT) >> > > | >> > > | branch-1 (0.99.0-SNAPSHOT) >> > > | | >> > > | | >> > > |/ >> > > >> > > >> > > As a reminder, 0.99.0 release and any more releases in 0.99.x release >> > will >> > > be labeled as "developer releases" as a way to prepare for 1.0.0. >> 0.99.x >> > > will NOT have any forward / backward compatibility guarantees and not >> > > intended for production. I aim to get the 0.99.0RC0 cut by end of this >> > > week. We should only accept patches relevant to 1.0.0 release to the >> > > branch-1 from now on. On that note, it will be good to re-kindle the >> > > interest in jiras around >> > https://issues.apache.org/jira/browse/HBASE-10856 >> > > . >> > > Please feel free to pick up any issue that you consider important to >> fix >> > > for HBase-1.0 release. >> > > >> > > Jira labels: >> > > - I've created 2.0.0 label in jira. We now have 0.99.0, 1.0.0, and >> 2.0.0 >> > > labels corresponding to branches in progress. If you commit anything >> to >> > > master, please mark the jira with 2.0.0 label. >> > > >> > > Jenkins builds: >> > > - I'll set up a build for HBase-1.0 using JDK-1.7. >> > > >> > > >> > > Your RM, Enis >> > > >> > > [1] >> > > >> > > >> > >> https://mail-archives.apache.org/mod_mbox/hbase-dev/201406.mbox/%3CCADcMMgEhM1rN4AsazErDAUqXO5fcCbgcRz%2B2nDXo9q2CQL%3D7jg%40mail.gmail.com%3E >> > > >> > > [2] >> > > >> > > >> > >> https://mail-archives.apache.org/mod_mbox/hbase-dev/201406.mbox/%3CCAMUu0w-qWXnHRewuqo1NpSnD6Kj0aad9LcmyuLJ%3DskQ8Ut9sYw%40mail.gmail.com%3E >> > > >> > > [3] >> > > >> > > >> > >> https://mail-archives.apache.org/mod_mbox/hbase-dev/201406.mbox/%3CCAMUu0w-3rkvabadvkYtfjiE24yr-wKLx0%2BcXEvcFTyK1VSiDBQ%40mail.gmail.com%3E >> > > >> > > [4] http://semver.org/ >> > > >> > >> > >> > >> > -- >> > Kevin O'Dell >> > Systems Engineer, Cloudera >> > >> > > > > -- > 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)
