At the moment - next to 2.x.

After the 1.2 release, the ideas getting throwing around for example were to rewrite the web services layer e.g. to support soap/xmlrpc etc, to look at objects/exceptions and replace adodb.

I know some of those ideas/plans probably pre-date some of the people that have recently worked on things.

Personally, I was under the impression that we probably wouldn't release a 1.3 but skip to the 'next' idea, hence I've not put any development effort into their branch. I know dhx/others have kept a rough eye on the branch I was keeping, and I know i've got several lists of what's been done in master/1.2.x/next that need merging.

I can't recall why Dhx hasn't been around as much recently - I know in the case of John Reese he's stated that he won't be working on php projects anymore  (, and we've picked up yourself as an active developer + rombert on the soap api and atrol on the bugtracker.

From my point of view, I'm going to work on the branch in master-2.x for another 2 months until December to get it into a state it could be put forward as something we could start to organise a release around (as the current 1.2.x code is not suitable for use on Microsoft SQL Server which I use at work, and the concluded fix for that was to lose adodb), with the fixes in the current master. It was around April 2011 that we first started looking at "next" and I don't there has been any major development on the master branch by myself (or dhx) since.

This basically means spending a week getting dhx's locale changes redone (which is ~half way through), setting up an automated build of the phpdoc stuff + demo instance (as it now builds without errors) so would be nice to keep it that way, and then spending 6 weeks tidying up the objects/exceptions/db layer. This would then put us in a position where we can have a proper look at whether the changes would be an improvement on the 1.x version or not. 

And to come back to dregad's original mail:

"At some point I even thought he was going to fork (i.e. the mantisbt2 org on github)" -> the reason for creating this at the time was as the DB layer changes, it would require plugin's to be updated, which whilst trivial I thought could make more sense to manage as a seperate organisation - however, i'm also fairly sure someone said that wouldn't be needed due to how git/github works.

"therefore intentionally not included some commits to master, not to mention dumped the soap api entirely" -> a) there's a couple of changes in master that do not make sense. For example, if you look at daryn's original work to re-organise the mantis file layer - that negates about 3 commits to master that deal with out we calculate paths correctly or incorrectly in some cases. In terms of the 'soap api' - I consider that as temporary. The current soap api 're-implements' too much of the mantis code base, only supports soap and was written *before* mantis supported multiple projects/configs etc - and whilst it works, and rombert has done a great job of improving it -  It's also fairly high up on the list of things in mantis that needs to be looked at from scratch. For 3 reasons:

a) a number of other projects now support multiple webservice layers (rest/soap/xmlrpc). There's a few projects out there, and even the zend framework that allow you to organise things in such a way that you can have a webservice class that can output soap/rest/xmlrpc as required depending on the client.  I know dhx has reservations about that sort of approach. Rombert's probably in a better position to see if that sort of approach is likely to work.
b) the webservice layer should be a loose wrap-around mantis - when i last looked there were some places it had to do db queries due to how mantis currently works.
c) some of the calls I think still need updating to support multiple projects/configs - For example, mc_enum_status - I believe you can't specify a user/project id.

Now having said all of that... i'd probably be inclined to sit down and take the latest soap api and make it work with the 2.x codebase. Whilst simultaneously starting the discussion on whether we should implement a new web service layer that supports multiple outputs and treat the existing one as supported but 'legacy'. Or whether if we want a xmlrpc webservice api, we code it from scratch alongside the soap one etc etc. As a reference to the 'multiple outputs' - and give two approaches.

'dhxs personal repo':
12:05 paul: what do we do with the next branch at end of this
12:05 paul: leave in place or rename or what
12:07 dhx: I'll move it into my github repo


On Sun, Nov 4, 2012 at 11:05 AM, <> wrote:
Paul Richards <> wrote on 02.11.2012 23:04:35:
> I sat down with dhx last week and we compared the 2.x and next
> branch - came up with a list of about 10 commits to migrated into
> 2.x so we can move the next branch to dhx's personal repo.

Well that's good to hear.

Can you confirm what is the direction of the cherry-picking

- from next into 2.x or
- from 2.x into next

And the mention of 'dhx's personal repo' confused me... can you clarify what you mean ?


This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith.

Click to access the German, French, Spanish and Portuguese versions of this disclaimer.
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
mantisbt-dev mailing list