1. OpenSAF Developer Days 2008 OpenSAF Release Management Session 15-07
Steve Constant
R2 and R3 Release Manager
October 15, 2008

2. Introduction
Branch Management
Version Number
Roles and Responsibilities
Special Presentation

3. Branch management
OpenSAF will maintain a total of three(3) branches/Repositories at any given time
One development branch
New features and bug fixes
Backward compatibility with previous releases may not be maintained.
Two “stable” (“bug fix”) branches
Bug fixes only
Backward compatibility within the stable branch will always be maintained.
Overview of activity on any branch/repository can be found at:

4. Development Branches Managed as a series of Beta Releases
A beta consist of
One or more features
A set of defect fixes
A beta is announced to the overall community for testing and defect fixing
Functionality Complete takes place at the conclusion of the last beta
One or more Release Candidates will be made available as needed.
Intended to tested by the community
Managed under change control
A General Availability release is provided when the latest RC is considered stable.

5. Development Branch Contributions
Other Changes
Bug Fixes
Roadmap
Features

6. Stable Branches (a.k.a Bug Fix branches)
Managed as a series of “Patch Releases”
Only two (2) Patches Releases will be supported by OpenSAF at any given time.
Each Patch Release consists of one or more bug fixes to a stable branch.
Many Patch Releases can be made to a single Stable Branch.
Typical Patch Release LifeCycle
Development period (contributions, no change control)
Functional Complete milestone (no more contributed fixes for this patch release)
Release Candidate (community testing and change control)
Patch Release

7. Version Numbering
First number is stepped for major release (major change)
During development only first two numbers are used joined with milestone designation
Patch releases step third number:
Example
3.0-M0 (Base milestone from on GA)
3.0-B1 (First Beta for 3.0 Release)
3.0-M1 (First Milestone for 3.01 Release)
3.0-B2 (Second Beta for 3.0 Release)
3.0-M2 (Second Milestone for 3.01 Release)
...
3.0-B9 (Ninth Beta for 3.0 Release)
3.0-FC (Functionality Complete)
3.0-RC1 (Release Candidate 1)
3.0-RC2 (Release Candidate 2)
3.0.0 (General Availability for Release 3)
2.0.0 (GA release for Release 2)
2.0.1 (Release 2, Patch Release 1)
2.0.2 (Release 2, Patch Release 2)
...
4.0-M0 (Base milestone from on GA)
4.0-B1 (First Beta for 4.0 Release)
4.0-M1 (First Milestone for 4.01 Release)
4.0-B2 (Second Beta for 4.0 Release)
4.0-M2 (Second Milestone for 4.01 Release)
...
3.0.1 (Release 3, Patch Release 1)
3.0.2 (Release 3, Patch Release 2)
...

8. Roles and Responsibilities
Fully documented at
User
Someone who uses OpenSAF software (end user or applications developer). May submit bugs reports, and provide feedback to OpenSAF developers.
Developer
Someone who contributes to OpenSAF in the form of code and documentation.
Module Owners/Committers/Maintainers
A developer who has write access to a code repository. Responsibilities include:
Working with developers to reviewing and approve bug fixes, patches and features.
Contribute new features and patches
Respond to code queries
Release Manager
Manages OpenSAF Releases
TLC/TCC
Technical expert group responsible for leading the OpenSAF project.
Responsibilities include:
Defining and maintaining the roadmap
Critiquing and review requirements, design and architecture.
Documenting coding guidelines.

9. Questions

10. Most Active 2.0 developer !
Special recognition for two of the most active OpenSAF developers to date!
Each receive a Acer Aspire One 8.9-inch Mini Laptop