ScienceSim Development Procedures

THIS IS A PROPOSAL/WORK IN PROGRESS

ScienceSim attempts to provide a relatively stable release. TBD: What is Stable? The goal of 'stable' is to promote the development of applications on top of a release by holding feature and API changes to a minimum. A 'stable' release will have a known API and be straight forward to build, install, configure and run.

TBD: Describe the process for building a roadmap. Related to the biannual release cycle discussion below.

We use git to manage source code distributions. Git can manage multiple branches in the same source tree. We expect to use that feature to facilitate our development process.

The current stable distribution will be available in the git branch “scisim-stable”. This is expected to be a stable, tested code base with API consistency measured in months.

We will provide a bug fix release every two weeks. The release for the following week will be in a branch of its own. That branch will be labeled with the target date for its release. For example, the Nov 25 release might be labeled “scisim-RC-2009Nov25”. The bug fix release will be frozen one week prior to the actual release and will be tested. The release manager will make the decision on the actual release date.

The branch for the following bug fix release will be created when the current bug fix release is frozen for testing.

The expectation is that the bug fix release focuses on fixing small problems that do not require significant internal refactoring. The bug fix release is limited to changes that will not break backward compatibility of applications and scripts. Configuration changes must be optional. Changes in APIs must not affect the behavior of region modules or scripts. Performance improvements are acceptable so long as backward compatibility is maintained.

After testing, the bug fix release branch will become the stable release branch. That is, the bug fix release branch will be merged into “scisim-stable”.

Around twice a year we will provide a feature release. The expectation is that we would include advances from the OpenSim development community and specific features developed by foundation members. There will be a “scisim-experimental” branch that consists of a set of features proposed for the next release. Approximately two months before the proposed release, an engineering advisory board will meet to decide which of the proposed features will be incorporated into the next feature release. That release will be created as a new branch and will be tested. At the end of the test period, that branch will become the new “scisim-stable” branch.

Feature releases may include new APIs and mandatory configuration changes. Any feature that breaks backward compatibility must be documented and reviewed prior to inclusion.

TBD: Describe testing process (there must be one) for each kind of release.

• Apache
• Mozilla
• Xen