I'd need to do a rough comparision of 1.2<>master branches to see whats changed and **not** been backported already before commenting properly.
My personal focus at the moment has been with the db layer and objects. Historically, I tend to find time during August, then again in October to work on mantis, so personally i'd like to conclude my 'ideas' during next month.
dhx has similarly been playing with a seperate 'next' branch.
Daryn has been having some looks at restructuing/lithium/etc.
So ultimately at the moment we've got a number of experimental branches around.
If we assume that people are focusing on those areas and that we call that work '2.0' for a moment - i'm assuming potentially it's a major change for plugins etc, I think we need to be careful how much work we put into 1.x in general - at least - we need to bear in mind that anything we commit to that branch will probably need manually rewriting and porting to the new branches.
Personally, I thought the decision people were going towards back in May/June when we pretty much stopped working on master for other branches was that some of the ideas in development should be what formed part of the next release of mantis - albeit, we hadn't really concluded what.
Having said that... I'm also aware that our release style tends to lead to long gaps between releases - which we've also agreed needs to be avoided :)
The main thing I feel is broken at the moment and needs fixing in our 1.2 branch(es) is our database support, Up until 17th May 2010, we'd always included a customised adodb version with mantis that fixed some issues in support for databases like oracle, mssql etc. Those files were then included in the 1.2.1 and removed by the 1.2.2 release - effectively breaking MSSQL support. I'm still running version 1.2.1 of Mantis at work due to that change, and that was the reason for spending some time a few months ago looking at the DB layer [in 'next/my github branch'] - that is something I'd aim to get completed between now and xmas at the latest, and push for getting that code out into some sort of alpha release for testing.
- How big is the 1.2<>1.3 changeset?
- Can we release 1.3 'now' with whats been done so far without doing addition work that may require manual porting later on?
- Does anyone have an overview of any new features between the current 1.2 and 1.3 branches
On Tue, Sep 27, 2011 at 9:55 PM, Robert Munteanu <email@example.com>
I am starting to feel quite anxious about moving 1.3.x out the door.
There are two reasons for this:
1. 1.2.x is one and a half years old and no longer receiving improvements
2. I feel that much effort is being put into the next ( 1.4 ? )
branch, which will not benefit users in the short term
I think that the most of the development team feels that once a
version - e.g. 1.2 - is pushed out it should only receive bugfixes and
feature work should focus on the next version. I'm not necessarily of
that opinion, but that's not what matters right now. What does matter
is that we are lagging in terms of feature releases and should focus
on getting 1.3 out the door sooner rather than later. User perception
is not affected only by feature completeness ; perceiving the project
as alive and vibrant is important as well.
I would like us to agree on a list of must-haves for 1.3 . The roadmap
for 1.3.x  sets us at 70 of 160 issues resolved . That's not going
to happen in a week. Or ten , by that matter. I suggest splitting the
issues between 1.3.now and 1.3.later - or whichever names you find
For 1.3.now, there are few technical/administrative issues which we
must have, which are:
- up-to-date documentation for users, administrators and developers
- clear migration path for plugin developers
- visual, 'shiny' release notes which will promote our latest and
greatest - see for instance 'Top features' from
Other than that, we must agree on a manageable list of features from
those targeted for 1.3.x and cut a first pre-release from it . And
then focus on stability and allowing plugin developers to update for
I hope I've been clear enough and I also hope that you (mostly) agree
with me that we should focus on 1.3 .
Sent from my (old) computer
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
mantisbt-dev mailing list