Thanks for bringing this up again. I still stand by Hybrid A, but I'm not going to oppose Hybrid B in any way - not even thinking about it.


On Thu, Jun 13, 2013 at 6:01 AM, Victor Boctor <> wrote:
Thanks Roland for the nice overview.  +1 from me.  The deprecated/cut features make sense to me.

I think it is fair to have Damien work on master since his work is getting us closer to shipping.

On Wed, Jun 12, 2013 at 1:25 PM, Roland Becker <> wrote:
I just want let you know that I changed also my vote from Hybrid A
(branch 1.2.15) to Hybrid B (recycle master) [1]


1) The mentioned reverting of some commits will help to fix the
blocking issues (language format, XHTML) [2]

2) Having a backward compatible version of db_get_table will help to run
some old plugins without changing code.

3) Damien is working on it [3] .

4) I don't believe any longer that we will see a master-2.0.x in near future.
(so master will preserve at least some of the work that has been done already)

Certainly we should be aware that following this approach also means
loss of some functionality of 1.2.x. (no problem for my installations)

- Extended project browser [4]
- Built-in source code integration support [5]

It would be fine if there is some kind of official commitment/decision
to Hybrid B.

If no one objects Damien would not have to work any longer on his local branch
but could go on using our master branch for it.



> Victor Boctor <> hat am 5. Juni 2013 um 04:05 geschrieben:
> I'm OK with attempting to use master as the basis for 1.3 while
> reverting the changes that block us from moving forward.  We can
> probably take a stab at the initial list of reverts (as per the thread
> below), but possibly add more fixes / reverts as we discover issues.
> The following criteria act as my litmus test for success:
> 1. Being able to resolve 1.3 blocking issues (
> )
> 2. Being able to release 1.3 within a couple of months.  I would
> expect that we will need to release release-candidates before
> releasing the final stable release.
> We should make sure not to bite too much and try to land too many
> things.  The worst thing we can do is to end up in a situation where
> we still can't release for months or even worth release 1.3.0a1/rc1
> that users upgrade to and then get stuck with issues and not having
> enough bandwidth to land all these issues to deliver 1.3.0 stable.
> Just remember that we all have a life + job :)
> In the meantime, until we have a proven dev and stable branches.  I
> expect that we will need to continue to deliver bug fixes and some low
> risk improvements into master-1.2.x.  Once we release 1.3.0, we should
> be able to higher the bar, since at this point we will go back to
> having a healthy master and 1.3.x that enable us to increase the fix
> bar.  It is fair to expect that changes in 1.2.x should also be
> checked in master by the same developer.  Unless, we don't release off
> master for an extended period of time, in such case we will have to
> revisit the conversation.
> -----Original Message-----
> From: David Hicks []
> Sent: Tuesday, June 04, 2013 5:44 AM
> To:
> Subject: Re: [mantisbt-dev] 1.3, 1.4, master/next/2.0, etc
> On Tue, 2013-06-04 at 12:29 +0000, Damien Regad wrote:
> > Yes I'm aware of that, and indeed that (and other security-related
> > enhancments) is one of the many reasons why I think it's better to
> > reuse master vs cherry-picking things onto 1.2.
> Aha, I misunderstood the intention as using 1.2.x and cherry-picking from
> master. It makes a lot more sense to use master and revert/rebase out
> unwanted changes.
> > But that is completely independendent from the use of XHTML-strict,
> > isn't it ? What I meant was reverting the html_begin() api from
> Yes. XHTML strict is really just a debugging tool for developers/plug-in
> authors. It can also make XSS attacks harder to pull off -- noting that
> Content-Security-Policy is a much better level of protection. I don't see
> any problem moving back to transitional XHTML for an interim 1.3.x release
> series.
> > I believe Paul has integrated this in his 2.0 branch, so that would be
> > the "future" way - we are talking about a transition period here.
> Yep, sounds good.
> > The latter is nice because it's less verbose in the code (and avoids
> > having to revert all calls to db_get_table in master branch), and the
> > former allows compatibility of plugins, etc.
> Sounds good.
> > Are you referring to something that is currently not in master, or
> > requires updates/changes ? If so, could you be more specific ?
> Ignore this point -- I was working on the wrong assumption that the current
> head of master-1.2.x would be used as the basis for a new master-1.3.x
> branch).
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> _______________________________________________
> mantisbt-dev mailing list

This email is sponsored by Windows:

Build for Windows Store.
mantisbt-dev mailing list