Freezes, Releases and Versions

Owned by Former user (Deleted)
Last updated: Jun 30, 2007Version comment
2 min read

Freezes, Releases, and Versions

Summary

  • Freezes
    • What does "code freeze" mean to you?
    • What should it mean for Sakai?
    • Should we have a timleline of freezes for different purposes?
  • Releases
    • Current version of "release" document
    • Should we have "official" releases and "provisional" releases?
      • Official ones would only include Supported projects and would be QA'ed
      • Provisional ones would include Supported and Provisional tools, but without extensive QA; and could be released more often?
    • What belongs in an official release?
    • How to handle big changes to supported projects?
      • Should they spend time as an optional piece? (sort of like Provisional; implementers can choose the existing Supported one, or decide to live on the edge and use the new Provisional version)
    • Cut back to one release per year?
    • Framework Release versus Project Team releases?
  • Versions
    • What to do about interim project team releases (e.g., a post-2.4 but pre-2.5 release version of Rooster, Assignments, Resources)?
    • Do we have a Framework version, and then each project team is free to do its own thing? (Means we need to split Jira up into separate "projects", rather than the current method of "components" in one project.
  • Branches
    • What type of branches do we want to support and how should we label them?
      • Production?
      • Maintenance?
      • Secuirity?
      • Trunk?
    • How do tags figure into this, especially if the release process changes?
    • New versioning scheme?
    • What to do about interim project releases (e.g., a post-2.4 but pre-2.5 release version of Rooster, Assignments, Resources)

Strawman Proposals for New "Freeze" Structure

  • [Gnome Example?]
  • Split up into a timeline of freezes for different purposes:
    • Feature Freeze (4 months out) – Updates of tool and service specification must be published for work intended for the next release.
    • Specification Freeze (3 months out) – The functional designs or specifications are frozen.
    • Upgrade Freeze (2.5 months out) – Upgrades to shared/common jar files and tools (e.g. java, maven, dbcp, spring, hibernate, tomcat, ...) are completed.
    • Code Freeze (2 months out) – Coding stops on feature development; only bug fixes allowed going forward.
    • String Freeze (1 month out) – No more changes in UI text, so the Internationaliztion WG can create translations and the Help WG can appropriately update documentation. Implementors can also start work on updating local documentation.
    • Branch Freeze (2 weeks out) – Branch for release is cut from trunk. No more revisions picked up from SVN unless they are associated with a Blocker issue.