From xemacs-m  Wed Jan 22 18:46:53 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
          by xemacs.org (8.8.4/8.8.4) with ESMTP
	  id SAA12102 for <xemacs-beta@xemacs.org>; Wed, 22 Jan 1997 18:46:51 -0600 (CST)
Received: by crystal.WonderWorks.COM 
	id QQbzqx18191; Wed, 22 Jan 1997 19:46:52 -0500 (EST)
Date: Wed, 22 Jan 1997 19:46:52 -0500 (EST)
Message-Id: <QQbzqx18191.199701230046@crystal.WonderWorks.COM>
From: Kyle Jones <kyle_jones@wonderworks.com>
To: xemacs-beta@xemacs.org
Subject: Re: 20.0 release schedule
In-Reply-To: <rvg1ztjmn3.fsf@sdnp5.ucsd.edu>
References: <m2k9p7jo6f.fsf@altair.xemacs.org>
	<u94tg922e0.fsf@neal.ctd.comsat.com>
	<QQbzpp11213.199701221620@crystal.WonderWorks.COM>
	<m2k9p57gee.fsf@altair.xemacs.org>
	<QQbzqo16320.199701222234@crystal.WonderWorks.COM>
	<m2wwt5uxad.fsf@altair.xemacs.org>
	<QQbzqs17266.199701222343@crystal.WonderWorks.COM>
	<rvg1ztjmn3.fsf@sdnp5.ucsd.edu>

David Moore writes:
 > Kyle Jones <kyle_jones@wonderworks.com> writes:
 > 
 > > Translating that in XEmacs-speak, given the size and
 > > complexity of XEmacs, I'd expect moderate level bugs to be
 > > addressed in a release three weeks after the first rollout,
 > > assuming that the bugs are actually fixed by then.  If the
 > > bugs aren't fixed then an interim release is, obviously,
 > > pointless.  And The point of the release shoudl be
 > > increasing stability, no new features, no matter how
 > > tempting.
 > 
 > Hmm, at what points do we add features then?

At the points where you would have done a normal release, anyway.
The point isn't to stifle process, but rather not to hold bug
fixes hostage because of a release schedule that is generally
tied to new features.

 > Or do we maintain two code trees?  One which is 20.X.? == 20.X
 > + bug fixes, and 20.(X+1).p == 20.X + bug fixes + new things?

Yes, two code trees, or use a revision control system, or whatever.

