OSx4.0 -> OSx4.4

Eric Bergan eric at pyramid.pyramid.com
Sat Apr 22 03:09:27 AEST 1989


In article <66983 at pyramid.pyramid.com> csg at pyramid.pyramid.com (Carl S. Gutekunst) writes:
>That's all anyone gets. The letter denotes a "checkpoint" release, which is
>done when a change occurs that cannot reasonably be done in a PTF, but we are
>not ready for a full release. Normally all PTFs will also be folded into the
>checkpoint, too. When a checkpoint release is done, the previous release (as
>in 4.4 or 4.4b) is no longer shipped. But, like a PTF, the checkpoint release
>is not "announced" to the existing customers the way a full release is. You
>have to ask for it.

	The philosophy of a checkpoint release is a little more than
what Carl has stated. The primary purpose of a checkpoint release is
to generate a stable, tested release that has the PTFs integrated in.

	PTFs are generated to fix problems reported from the field, and
are tested to make sure they fix the problem and don't break anything
obvious, but they are bug fixes, not real releases. A checkpoint release
takes all the PTFs up to that point, and generates a release that then
goes through the full QA procedure, including stress and regression
testing. That way, we can document that no contention has slipped in
between different PTFs, or between a PTF and the previous base system.

	A checkpoint release can also be used to integrate in changes necessary
for new (or revised) optional products.

	The intent is to generate checkpoint releases on a reasonably
fixed basis, about every three to six months, based on the the number
and severity of the PTFs that have been accumulated.

								eric
-- 

					eric
					...!pyramid!eric



More information about the Comp.sys.pyramid mailing list