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

Introduction Branch Management Version Number Roles and Responsibilities Special Presentation

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: https://devel.opensaf.org/wiki/SourceCodeRepos

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.

Development Branch Contributions Other Changes Bug Fixes Roadmap Features

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

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 2.0.0 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 2.0.0 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) ...

Roles and Responsibilities Fully documented at http://download.opensaf.org/foundation-docs/Technical_Operating_Procedures_V_1.1.0.pdf 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.

Questions

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