Time for a 4.8.4 release
dmorissette at MAPGEARS.COM
Tue Jul 11 08:49:25 EDT 2006
Stephen Woodbridge wrote:
> but WHEN is the time to ask for fixes or to review open bugs for
> potential inclusion in maintenance releases.
There is not really a set time to discuss bug fixes for maintenance
releases since there are no set time for maintenance releases, we just
do maintenance releases when we feel there are enough bugs in the stable
CVS branch to warrant a release. If there are bugs you feel should make
it in a maintenance release then they should be discussed as early as
possible, and preferably not when there is a proposal on the table to
release the current (committed) fixes.
If you take 4.8.4 for instance, we released 4.8.3 on March 30th, so
anytime between March 31st and 2 days ago would have been a good time to
discuss/fix bugs. Today is not a good time because there is a proposal
on the table to release the current CVS code as 4.8.4.
> There is never any urgency
> around fixes until someone talks about a release.
True, and that's the habit I am trying to break.
> I don't think these
> are so much favorite wishes as much as legitimate request for known bugs
> to be fixed. I'm happy to debate if a bug should or should not be part
> of a major, minor or dot release.
Please keep in mind that pointing out that a bug should be fixed for a
given release (or even voting a motion to that effect) doesn't
necessarily mean that it will get fixed. You also need one of the
developers to take the time to do the actual work (or review/apply a
patch and vouch for it), and this happens only if this bug gets high
enough in one of the developers' priority list.
Another important point to keep in mind when considering bugs for
maintenance releases is that we should never commit new features to a
stable branch: only critical fixes. New features can only go in the main
development trunk. This is to keep the stable branch as stable as
possible. I'm not arguing that the bug that you (SteveW) raised was a
new feature, I'm just reminding everyone of that rule from RFC-7.
If some bugs systematically fail to be addressed then it is likely that
they are not high enough in any developer's list. If a bug is a high
priority for someone then one way they can influence priorities is by
offering one of the developers to fund the fix. Most of us keep our
paying clients at the top of our priority lists and will address bugs
for them within days (or within hours when possible).
More information about the mapserver-dev