I agree that it would be easier identify issues in master that we want to revert or improve.

+1 for finding out list of fixes in 1.2.x that is not in master.

For the DB fixes, I think it is OK to have tactical fixes based on adodb with vision to change to an alternative approach that gives us better story in the future.  An important part of the cross-RDMS support story is to have a continuous integration that provides such checks after every checkin.  If not, then we will always end up risking breaking database types that we care about.

My preference is to not change the DB layer as part of 1.3, otherwise, we will end up with something that is less likely to ship even compared to master and master-1.3.x, since this will be even more churn.

On Thu, Oct 3, 2013 at 2:36 AM, Damien Regad <dregad@mantisbt.org> wrote:
On 03.10.2013 00:34, Paul Richards wrote:
> I'll try and finish that up tomorrow and construct a 1.2.x based master

Please don't construct anything on top of 1.2.x and use master instead
as your basis.

As I told you several times, it will be much easier and less effort to
*remove* the things included in master that shouldn't be released rather
than doing the reverse. master has always been the official "next"
version, and I don't agree with throwing it all away without a clear
rationale (i.e. just because you say so).

If it really has to come down to that (I doubt it), this should be a
formal decision that a everyone in the team (or at least a majority)
adheres to.

> [and a list of patches not merged in so we can go through them]

That would be very useful. Thanks.

October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
mantisbt-dev mailing list