Add MariaDB as MySQL compatible (some linux distributions, eg RHEL uses it as default)

Good point, especially as MariaDB is gaining more widespread acceptance and they are diverging from MySQL.

Proposed:

• MariaDB 5.5.x (I was not able to find which exact version supports utf8mb4), recommended 10.x

I would also factor in Ubuntu as a distribution. We should be able to work with 14.04 LTS+.
http://distrowatch.com/table.php?distribution=ubuntu

PHP 5.5.9
MySQL 5.5.35

I agree with recommending PHP 7 going forward.

We should also clarify the browser compatibility as well. @syncguru can comment on that. But I generally would like to avoid supporting browser versions that are not supported by the company that released them. They may work, but we don't have to support them and could over time take dependencies that are not compatible with them as we modernize the UI more.

We should be able to work with 14.04 LTS+. [...] PHP 5.5.9

OK, I'll update the description.

as referenced in 0021883
Schema upgrades dont work properly with mssql. Installation seems not to be possible as is.

Just for the record: You drop for no need those single developers like me with
IIS7.x on Win7 (IIS8, despite Express is a no go there). No problem with MSSQL >= V2012.

@obmsch this is an open discussion at this stage. My proposal is based on what I found as supported on Microsoft website.

Note that having a minimum requirement does not mean that we will make use of specific functionality in that version, just that we don't test/support that version. Running Mantis on a Win7 box is most likely not a production scenario, and a developer using such config I'm sure will be able to live with that.

That said, I have no particular issue with listing IIS 7.0 as minimum requirement, and 8.x as recommended.

Ok, and to clarify thats IIS7.5 (Win7 and Windows Server 2008 R2)

@obmsch After verification, Windows Server 2008 R2 SP1 is supported until 14-Jan-2020 [1], so I downgraded IIS requirement from 8.0 to 7.5.

[1] https://support.microsoft.com/en-us/lifecycle/search?alpha=Windows%20Server%202008%20R2

As this will be a major new release (1.x.x -> 2.x.x) the stated requirements and recommendations should be fulfilled. I don't care about the past, but at least this time it should be done right.
So for me its either drop some os/db/provider from the list or resolve the open issues before a release. And as its stands installation/upgrade at least on mssql doesn't work.
I don't ask for any core developer to fix, maybe the community help out, but in the end you really can't state "mssql >= 2012" or "oracle >= 11.2" if issues like
0021901, 0021890, 0021883 are not resolved.

I strongly recommend to link in all open issues of this kind (as blockers) here and either resolve or drop the belonging os/db/provider(apache,iis,...) for now.

A skilled user might be able to install/upgrade nevertheless (I have done 1.2 -> 1.3 -> 2.0rc1 with iis/mssql - despite this has never working out of the box), but what kind of support would be there for all the others then?

So actually install/upgrade on:

1. mysql Ok
2. postgres?
3. mssql not working
4. oracle not working

I fully agree that these should be fixed, and it's not right to list a DB as "supported" if installation does not work out of the box.

On the other hand, considering another signification of "supported", meaning that MantisBT team will accept (and try to fix) issues on these RDBMS*, assuming we are not able to address the blocking issues prior to 2.0 release, I would prefer to list these DBs as "experimental", explaining in the documentation that some manual adjustments are required for the system to install.

• as opposed to e.g. DB2, that we decided not to support any longer

I agree that our messaging should be clear in terms of DBMSes. In some cases, a customer may be able to go with MySQL or Oracle. And if we advertise similar support, they may go the Oracle route and have issues during installation or even worse later on or when upgrading to next release.

Let's face it, our MySQL support is the only support that every developer tests and we would be blocking releases for. If MySQL is broken, it will take few hours to fix. If Oracle is broken, it takes a much longer time to fix.

So I recommend having our message clear that MantisBT team is focused on MySQL (and its compatible flavors like MariaDB). The rest are "community supported" with a link to a filter of issues open for the DBMS. This encourages customers to make the MySQL choice unless they have the resources to troubleshoot, fix, and contribute fixes.

As @dregad said, we would still accept contributions, potentially core developers may make some fixes themselves, but it is unrealistic to indicate same level of quality or focus for non-MySQL.

I would rather drop support of non-MySQL databases all together, due to some of the reasons mentioned above. But if we do keep them, we should be realistic about the level of support compared to MySQL.

See 0017336:0040594 for my opinion, just replace 1.3 by 2.0

MySQL 5.5.35

We will rule out Red Hat Enterprise Linux 6.7 with it, see also 0020431:0052214

RHEL-6.7 has been released 2015-07-22, is supported until 2020-11 and comes with MySQL 5.1.73
http://distrowatch.com/table.php?distribution=redhat

I am not sure if this is relevant for our decision, since we don't have any usage statistics for Mantis installations.

We will rule out Red Hat Enterprise Linux 6.7 with it

True, but please consider that Oracle support for MySQL 5.1 ended in Dec 2013 (!).
I personally believe that we need to draw the line at some point... Proper UTF-8 support is important enough to justify this decision IMO.

Furthermore, RHEL is a (paid) enterprise product. A skilled sysadmin in a corporate environment should also be able to install a later release of MySQL, or they can decide to run Mantis 1.3 until they can upgrade to RHEL 7.3. I faced the same issue in my previous employer (that was on an old version of Suse/SLES, and I had to install newer PHP and MySQL versions).

PR https://github.com/mantisbt/mantisbt/pull/960

@obmsch in response to 0021841:0054532:

I marked MSSQL and Oracle as experimental for now, at least we don't falsely advertise it as operational when it's not.

I'm not keen on removing them completely, considering the effort that I put into getting these to work until today, and would rather try and fix the issues even if it's in a later release.