GNU make: Next release schedule.

[Paul Smith]

Hi all.

I'm announcing a schedule for the next release of GNU make, version
3.82.  I plan to kick off the release cycle by creating GNU make 3.81.91
(3.82 rc1) on Oct 1.  I'll create a release tarball and announce it in
the usual places, and give until Oct 15 for people to test it out.  Of
course if there are show-stopper issues I will release a new rc before
Oct 15.

At that point I'll evaluate where we are and decide whether we need a
new release candidate or not.  My goal is to get an official release out
by Nov 1.  My last release was on April Fools; maybe this one will be on
Halloween :-).  However, I won't make the release if there are serious
issues of course.

During the next two weeks I plan to finish up some performance/memory
improvements I've had lying around, related to secondary expansion etc.
As you all know there are still plenty of bugs and enhancement requests,
as well as patches, on the Savannah site.  I definitely will not be able
to satisfy all, or even most, of those.  However, judging by the number
of bugs marked fixed in CVS any new release will be an improvement and
if we wait for everything to be fixed we'll never get a release out.

If there are important issues you think must be resolved before 3.82,
please let me know.

I've created a new attribute in the Savannah bug tracker, "Triage
Status".  The idea is to mark whether a bug has been looked at or not.
I've only updated a few bugs so far; I hope to do more.  It would be
very useful if folks who are familiar with Windows can examine the
Windows platform bugs and either update the status or let me know and
I'll do it.  Or, fix the bugs of course! :-)


Going Forward

After the release, I'll be converting the GNU make CVS archive over to
git.  Windows folks, please let me know if you will be OK with this; I'm
not sure what the current status of git support on Windows is.

I'll also be instituting regular, time-based releases.  Probably every 6
months but maybe more often if activity warrants it.  The current method
of trying to fix everything before the release is not working,
obviously; let's try the "early and often" release model instead.  I'm
hoping that the improved branch support in git will let us work on
longer-term projects without having to delay bug fix releases.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist