Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Fri, 2 Feb 2001 02:25:28 -0500
From: "Roy T. Fielding" <fielding@ebuilt.com>
To: new-httpd@apache.org
Subject: interim release strategy
Message-ID: <20010202022528.A28821@waka.ebuilt.net>
Mail-Followup-To: "Roy T. Fielding" <fielding@ebuilt.com>,
	new-httpd@apache.org
References: <20010201230530.5741.qmail@apache.org>
 <004d01c08ca6$b849fbd0$92c0b0d0@roweclan.net>
 <20010202003548.A14305@Lithium.MeepZor.Com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13-current-20010115i
In-Reply-To: <20010202003548.A14305@Lithium.MeepZor.Com>;
 from Ken.Coar@MeepZor.Com on Fri, Feb 02, 2001 at 12:36:39AM -0500

> I am tracing a potential problem with mod_setenvif and conditional
> logging.  It may already be fixed in 1.3 HEAD, and an artifact
> of the IHS 1.3.6.4 version where the problem is being seen,
> but if not I would like to get a fix in for 1.3-STABLE.
> 
> Now is probably an excellent time for Roy to expound in
> detail on what his nomenclature would mean for this next
> release..

I was only going to apply it to the 2.0 releases, at least until
the nomenclature itself is stable.

There really isn't that much different from our current release
strategy except:

   1) the RM can tag the tree with a new version whenever they
      think it is buildable and is an improvement over the last
      released version of that tree;

   2) everyone should make a habit of noting things in STATUS
      whenever they think the tree is not buildable (or they are
      just about to do something significant that the RM should
      know about);

   3) nobody talks about releasing something until after it has
      been built and tested;

   4) nobody freezes the tree -- if it so happens that the tree is
      screwed at the point it was tagged, we just keep going;

   5) nobody gripes if we go through 52 minor versions a year.

What is the difference between stable and current?  No feature/fix
gets added to stable until after the same feature/fix has been added
and *released* in current, or (iff it cannot be tested in current)
the fix gets three +1 in RTC mode.  No architecture changes in stable.
No API changes in stable.

BTW, I would have tagged a 2.0 release last weekend, but it wasn't
buildable.  Also, I need to move Announcement out of the build tree
and move versions out of httpd.h, just to avoid some of the simple
errors that frequently ruin builds.

Right now I'm midway through replacing buildconf.  I was planning
to get it all done this week and tag something this weekend, but
a long-time friend has decided to surprise me with a visit this
weekend.  Ryan, feel free to tag the tree and build a tarball
this weekend as soon as you think it should be done (after all,
it only needs to be better than the last time we tagged).  We
can update the nomenclature later.

....Roy