Time based releases are a great idea for teams that have dedicated developers with plenty of time to contribute.  In our case, all of our developers are randomly available for ever changing lengths of time.  I believe it is simply unworkable for us at this time.

The reorg branch is probably the easiest to get up to date and in place.  I vote to release 1.2.6 and merge the reorg branch into master.  The db update is the next logical merge in my opinion.  I would like to see a bit more work on it first but it's nearly there.  

My branches ( refactor, templates, stored filters ) are not really ready to merge in as they have been primarily experimental and need significantly more work and/or thought.  Some (filters,my view/dashboard) would be much better redesigned as part of a larger rewrite.  With a reorg branch in place though I believe I could break these experimental branches into smaller commit-able features and hopefully contribute something useful.

Daryn

On Thu, Jun 23, 2011 at 5:26 PM, Robert Munteanu <robert.munteanu@gmail.com> wrote:
On Thu, Jun 23, 2011 at 12:19 PM, David Hicks <d@hx.id.au> wrote:
> On Thu, 2011-06-23 at 10:39 +0300, Robert Munteanu wrote:
>> Since 1.2.x is almost 1 and a half years old, I think that this is a
>> good time to wrap up a final 1.2.6 release and put the 1.2 branch into
>> critical/security bugfix only mode.
>
> I agree that a 1.2.6 release is probably needed sometime soon. There are
> however quite a number of issues on the 1.2.6 roadmap (see
> mantisbt.org/bugs) that I feel need some attention. Many have patches -
> although some of these need more work done before applying.

Random thought #1:

Push some of these to 1.3 and release once all are done  ? I will do
so for some of mine, e.g.

0008657: [api soap] custom filters
0012478: [db oracle] Installation with Oracle fails

Random thought #2:

Make time-based releases, which I am a great fan of. But I'm not sure
how that would work, given that we contribute mostly in our spare
time. We could aim for 'stable' 1.2 releases every 6 / 8 / 12 weeks
and push out the door whatever is ready. 

 >> It would make maintenance easier
>> and would allow us to focus on getting a first 1.3 milestone out the
>> door, hopefully with some noteworthy improvements which would
>> encourage our users to try it out. Up til now my policy was to apply
>> fixes to both master-1.2.x and master, but that is getting a bit
>> tiring, as sometimes they need manual tweaking.
>
> I strongly agree that applying patches to both branches is a major
> hassle.
>
> Paul, Daryn and myself have started a number of branches on Github that
> primarily look at:
>
> * Removing ADOdb and replacing db_api with a new OO implementation based
> on PDO (much of this effort has already been completed).
>
> * Reorganising the directory structure (will probably need to be redone
> again once DB stuff is completed).
>
> * The use of templating - or at least major decoupling of UI and logic
> in the code.
>
> I get the feeling that it would have been better to make many of these
> changes to the master branch "as it happens". We're stuck in the
> situation at the moment where there are 3-4 very promising development
> branches that will not merge together. IMO the source code is not
> modular enough at the moment to allow for rewriting major MantisBT
> components in branches and then merging them back in again.
>
> Any thoughts?

To echo John's thoughts, let's start merging them to master. Otherwise
the bits will rot and decompose.The sooner the better. I am willing to
test things manually myself, and also having the SOAP API tests in
place does give us a little safety net.

Given that you hinted that the code is not modular enough right now,
perhaps - like John said - merging the 'reorg' branch first would give
us the freedom to work independently in branches.

Robert

>
> David