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.
On Thu, Jun 23, 2011 at 12:19 PM, David Hicks <firstname.lastname@example.org> wrote:Random thought #1:
> 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.
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 theTo echo John's thoughts, let's start merging them to master. Otherwise
>> 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
> 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?
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.