The branch is ok -- 3_1 branch is intended for 3.1.x future releases indeed.

If we can commit to releasing 3.2 instead of 3.1.1 in case only bug fixes are present, then I'm ok with it. We'd also need to commit, in general, to release more often. So if we decide to release say every 3 months, then 3.2 can include all the bug fixes for 3.1.

If that's the case (and I support it wholeheartedly), why create a branch for 3.1 at all - we could just tag branches_3x?

Also, the release artifacts are named 3.1.0, suggesting there will be a 3.1.1 -- hence why I wrote this email. But again, +1 on:
* Not releasing 3.1.1, but instead 3.2
* Not branching 3x, but instead only tag it
* Name the artifacts of future releases x.y only.


On Fri, Apr 1, 2011 at 2:43 PM, Robert Muir <> wrote:
On Fri, Apr 1, 2011 at 8:42 AM, Robert Muir <> wrote:
> On Fri, Apr 1, 2011 at 8:31 AM, Shai Erera <> wrote:
>> Hi
>> I noticed that 3.1.0's tag in svn is
>> Should it
>> not be At
>> least, that's what's specified under "Publishing" on ReleaseTodo wiki.
> Yes, I did this intentionally to try to discourage a 3.1.1. Is it
> really necessary to have confusing 3-part bugfix releases when
> branch_3x itself is a stable branch?! Shouldnt we just work on 3.2
> now?

(sorry i refer to the branch, not the tag here, but i think it still
makes sense).

To unsubscribe, e-mail:
For additional commands, e-mail: