>> > The goal used to be a major release every three months, but we haven't
>> > met that in some time. And, since it seems like we are now putting
>> > out major releases in order to do significant upgrades and not just
>> > incremental stability improvements, I kinda think that a slower cycle
>> > (six-month intervals, say) might be a more useful goal at this stage.
>> > Has the core group thought about this issue lately?
>>
>> I got a good laugh on this one. That we actually planned ahead... :-)
Maybe the core team should take a look at the TODO list, and split it over
the next couple of release cycles. Then you can just say, when a and b and
c have been achieved, and are stable, then we release 6.x
This doesn't include bugs. Bugs must still be fixed and release in the
point releases, which should be every, say, three months.
As new stuff gets added to the TODO list (not bugs), it gets shuffled into
the release cycle. This isn't hard to manage once the first one has been
done, and you make a policy of only planning four or so releases ahead.
Then ou can post this plan on the web site, so that people know what stuff
is being worked on. Of course, CVS management becomes an issue, because if
someone feels like working on something that is not due for two releases,
does it go into the current source tree? If necessary, you can open up
branches for each planned release, and people can check out whichever one
they feel like working on. Of course, merging bug fixes becomes more of an
issue. Actually the more I think about it, the more complex it becomes, but
if the CVS management is not really an issue, then this is a possible
approach. Otherwise, we'll have to think of something else.
Of course, the core team are responsible for merging changes into the CVS
tree, so they could just implement a policy of only adding new functionality
that is required for the current release.
If somebody desperately wants something added, and can convince the core
team to include it in the current release cycle, then the code can be added
immediately (assuming that somebody has actually done). Alternatively, they
manage their own source tree, until such time as the code gets included.
MikeA
