Here is what I'm getting from Paul's summary, please correct me if my understanding is incorrect:

1. recommendation is to retire "next" is retired in favor of master-2.x
2. master-2.x will need some work to be ready with objects, exception handling, localization, and new gen web services.
3. master-2.x will support current soap api as legacy for backward compatibility.
4. master-2.x will break backward compatibility for plugins.
5. master (or what is designated as v1.3) may be skipped, assuming master-2.x is ready in the near future.

What I'm missing is:

1. What is in master-1.2.x that is missing in master? My assumption there will be few commits in this category that we can figure out easily.
2. What is in master-1.2.x and master that is not in mantis-2.x?  I expect a lot since development was out of sync, unless someone was actively doing these merges.  Some may be irrelevant to the new implementation, but I expect a lot to be.
3. What is in master and not in master-1.2.x?  What is the main value add so far of master (v1.3)?
4. What is the current status of master-2.x?  The estimate is 2 months for completion, but what is working? what is the progress?
5. How long do we expect for master-2.x to be stable for release?

For master-2.x to be our next major version, I would suggest the following:

1. Get it to a complete / stable state.
2. No take backs compared to 1.2.x as far as users are concerned.
3. Make sure all features / fixes in master-1.2.x made it to master-2.x
4. Backward compatibility with SOAP.
5. Port most popular plugins to be 2.x.
6. If we haven't started working on a new feature or refactoring, let's not do it.  For example let's not worry about REST or new web service implementation until we release master 2.0.  We can always add this later.

If we are not on track by end of the year, we may want to consider v1.3 off master-1.2.x or master to do the following until master-2.x is ready and stable:

1. Unlock features that require a schema change.
2. Bundle jQuery to enable mantis and its plugins to re-use it.
3. Drop nusoap and require php soap client.
4. Unlock bigger features that may be too big to include in a 1.2.x release.


On Sun, Nov 4, 2012 at 7:40 AM, Paul Richards <> wrote:
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

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