Pegasus Enhancement Proposal (PEP)

PEP #: 114

Title: Supported Release Process for Open Pegasus

Version: 1.3

Authors: Ed Boden

Status:  accepted

Created: 17 November 2003

Version History:

Version Date Author Change Description
1.0 3 Dec 2003 E.Boden  Initial Submission
1.1
 14 Jan 2004
 Ed Boden
 updates for 1st round of comments
1.2
 23 Jan 2004
 Ed Boden
 added release naming conventions section, updated process elements 6, 8 & 7 dropped.
1.3
 11 Feb 2004
 Ed Boden
 clarified example in basic element number 3.   minor rewordings, color coded.




 

Abstract: Define what a supported release means for Open Pegasus and describe associated processes.


Definition of the Problem

It is not currently clear what Pegasus releases are supported.   Nor is it clear what it means to be a supported Pegasus release.  And it is not clear on the web pages; there are inconsistent views across the Pegasus development community, and people shipping or using Pegasus have differing views.


Release naming convention

Pegasus releases use a 4-part designation (informally);  m.n.u[.evoN], for major release, minor relase, update to a minor release, and evo number n.   The basic intent is that MAJOR versions can be incompatible (for example, API or other interface upgrades).   MINOR releases retain source and binary compatibility with older minor releases (of the same major release), and changes in the update level are typically collections of bug fixes.   Numbers are used for major, minor and update levels.  The smaller designations may be omitted, in which case they are assumed to be '0'; for example, 2.4 is 2.4.0.    An 'evo' (see references in PEP 97) is a pre-release CVS tag (not an actual release) of development code, designated by the letters 'evo' followed by a number.   



Definition of the Proposed Solution

First we need some terminology; A 'back release' of Pegasus is any Pegasus release that has completed the SR (Ship/Release) milestone.   (The term 'current release' is widely used to refer to the main CVS branch (aka "trunk") in which development is happening (based on PEPs or bugzilla's).   Since this branch has not yet achieved SR its not actually a release yet, but rather a release wanna-be!    Anyway, the term will not go away.)

All back releases are  either 'supported' or 'not supported'.   (Hence, the current release is neither supported nor unsupported -- its development!  And outside the scope of this PEP.)   This PEP defines what it means for a back release to be a supported, and by implication, unsupported.


Basic elements of the Pegasus supported release process

  1. The OpenPegasus Steering committee, with advice and consel from the Architecture team, determines which back releases of Pegasus are supported.  
  2. At any one time, there will be at most two (2) supported back releases.   There may, occasionally, be less than 2 supported releases.
  3. Generally, the two supported releases will be the most recent point release within each of the previous two major releases.   So, for example, after 2.3.1 is SR'd, it will automatically become a supported release, and 2.3.0 will become an unsupported release.   Continuing the example, the other most recent point release 2.2.1, would by default, also be supported.  (As it happens 2.2.1 is not supported, as an exception to the general rule).
  4. Supported releases will be clearly marked as 'supported' on the Open Pegasus web site (on the Release Snapshot page, for example).  All releases not so marked are unsupported.
  5. Bugzillas may be written against a supported release and the Pegasus community will have visibility, communication and advice on these bugs.
  6. A person that fixes a bug in the current release is expected to consider whether the bug is applicable & important enough to also be fixed in supported releases.    If applicable & important, then it may also be fixed in the supported releases.   At the minimum, the bug fix person should indicate their opinion (say, as bugzilla comments) regarding applicabability and importance for supported releases. The comment 'it is unknown whether this defect affects prior releases' is an acceptable response. (see PEP 2 for the Bugzilla process.)
  7. Bugzillas may be written for an unsupported release, but can't be fixed in an unsupported release; changes to files in Open Pegasus CVS are not allowed for unsupported releases.   The resolution for such a bug would be 'WONTFIX' with a comment that states that the bug has been filed against an unsupported release.   (As usual, exceptions may be made by the Opan Pegasus Steering committee.)


Rationale

Clarify everyone's expectations and responsibilities with respect to back level Pegasus releases, so they can choose the Pegasus release the best meets their needs.   Hence, a key audience are people who ship or use Pegasus (write providers, etc.).   And, of course, the Open Pegasus development community needs to know, or be able to find out easily, what releases are supported.

Schedule

The goal is to have our definition of what it means to be a 'supported release', early in the Pegasus 2.4 cycle.

action
 planned
 actual
 comment
PEP submitted
 12/4/2003
 12/3/2003
PEP reviewed
 12/19/2003
 1/16/2004
PEP approved
 12/19/2003
 2/20/2004
 accepted in ballot 39
Code committed
 n/a
 n/a
 (This is a process PEP -- has no associated code.)



Discussion

Additional ideas for discussion, with consensus answers;

  1. A special case may occur when a new major release occurs, for example when 2.4.0 reaches SR.   For a limited period of time, the Steering committee may allow 3 supported releases, the 2 supported point releases and the new major.   If not explicitly decided, the new major release will cause the oldest of the supported releases to automatically become unsupported.   For example; when 2.4.0 reaches SR, 2.2.1 becomes unsupported and the 2 supported releases are [the expected] 2.3.2 and 2.4.0.    Conclusion: proceed as described above; of course, the steering committee (in its wisdom :-) may make exceptions.
  2. Should we expect that the bug fix person will also fix the bug in all supported releases (assuming its applicable and critical)?  Ans: no.
  3. It may be beneficial, or desired, to allow bug fixes and CVS updates for unsupported releases.   If we do this, we could define unsupported to mean bugs would not reviewed in bug conference calls, or similar.   Ans: allow bugs to be written for unsupported releases, but no CVS changes. The resolution for such a bug would be 'WONTFIX' with a comment that states that the bug has been filed against an unsupported release.
  4. Do we prefer different terms for 'supported' and 'unsupported'?;  active and inactive?  maintained and unmaintained?    nursed and  abandoned?  parented and orphaned?  washed and unwashed?  the quick and the dead?    Ans: active and inactice.
  5. Rather than allowing the pace of OpenPegasus new releases to drive the supported to unsupported transition, should we keep a release as supported for a defined length of time?   Say 2.5 to 3.5 years?   Is there a maximum amount of time?  (This may lead to the necessity of supporting more that 2 concurrent releases.   If so, what is the maximum number of concurrently supported releases?)  Ans: no fixed time.
  6. Should we provide a means on our OpenPegasus web site where a person that ships or uses Pegasus can indicate which release they use?   And perhaps also how long they would like it to remain as supported?  Ans: not formally, however, The Open Group and the Open Pegasus Steering committee welcome queries on this topic.
  7. Should the weekly bug call be done year-around?  This would be to help ensure & encourage appropriate level of support for supported releases, as well as helping drive a current release to closure.    Ans: pretty much.
  8. Should Pegasus adopt the m.n.u form of release designation?  Ans: this PEP does not suggest the change.
  9. Are changes to file in CVS for a unsupported releases actually disallowed by CVS?   Ans: yes, if possible, this should be controlled by CVS itself.
  
  

Copyright (c) 2003 BMC Software; Hewlett-Packard Development Company, L.P.; IBM Corp.;  VERITAS Software Corporation; The Open Group

Permission is hereby granted, free of charge, to any person obtaining a copy  of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

 THE ABOVE COPYRIGHT NOTICE AND THIS PERMISSION NOTICE SHALL BE INCLUDED IN ALL COPIES OR SUBSTANTIAL PORTIONS OF THE SOFTWARE. THE SOFTWARE IS PROVIDED  "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.