Good points, Andrew. The 4.0 branch should become master. I'm just finishing up a feature for 3.0. I'll cut a branch next week for 3.0, and then when Jeffrey does his re-base, he can move it to master.
We should have three branches: 3.0 - this will be the branch compatible with 0.94 2.0 - this is the current stable release that will get sub-planted by 3.0. I'd like to keep it in case we need to do patch releases. master - this will be the branch for 0.96 and 0.98. Once we release 4.0, we can create a 4.0 branch. Does that seem reasonable? Thanks, James On Saturday, February 15, 2014, Andrew Purtell <[email protected]> wrote: > Hi, > > There are several branches in the Phoenix repository: > > remotes/asf/2.2.3 > remotes/asf/4.0 > remotes/asf/4.0.0 > remotes/asf/HEAD -> asf/master > remotes/asf/master > > Is there a wiki page that describes them? > > In lieu of that, "2.2.3" and "4.0.0" look like release branches. "4.0" > looks like a feature/future dev branch, though it is a bit odd that > "master" seems to correspond with a "3.0" release line, when the usual > convention is "master" is the leading edge of commit history. Also, is a > "4.0.0" branch premature, or is there a 4.0.0 release actually being > staged? Thanks in advance for the clarifications. > > If we have a fix applicable to all branches, like PHOENIX-46, what should > we do as committers? I think typical practice would be to skip what look > like release branches, since they correspond to artifacts already produced, > and commit everywhere else. It would be a bit more comfortable and expected > in my view if "master" was 4.x, there was a branch for 3.x, and commits > would go to master, then be back ported to other active major version > branches as needed. For your consideration. > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) >
