Versioning: JIRAs and Release

[Chris Roby]

Hi everyone,

As we're about to release the 1.0 version of Sakai OAE, the project leads been discussing how we should handle our JIRA versions as we continue forward with development. We've come up with the following plan, and wanted to share it with everyone to both solicit feedback prior to enacting it and to give everyone a heads up as to the upcoming changes.

For vocabulary, a version number of 1.0.2 indicates that 1 is the major version, 0 is the minor version, and 2 is the revision version

1) UI and Nakamura will sync on the same major and minor versions as long as that continues to make sense to do.

2) The UI and Nakamura can release at different times if needed and feasible. These releases will be revision releases whenever possible, to avoid drifting the major/minor versions of Nakamura and the UI apart.

3) As JIRA can have multiple version assignments per issue, each issue will have two Fix Versions - The version and the sprint. This allows us to subdivide work while keeping the version numbers in sync. For example, a current UI JIRA for version 1.1.0 would have the two fix versions of '1.1.0' and 'Sprint 112'

4) Once we've released a version, we'll roll up all the Sprints into the release they were apart of, to reduce noise in the Version in JIRA. With the new JIRA versioning scheme as described in 3), this just means we'll delete the 'Sprint #' versions that were apart of a release, as they'll have also already have the release version set in their fix version. For previous Sprints that don't yet have a release version associated with them, we should create the release version (ie. '0.2') in JIRA, associate the appropriate Sprints with that release version, and then delete the Sprint association.

5) JIRA 'Affects Version' will always be the current version and sprint that is being developed for.

-- 
Chris Roby