Talk:Release Policy

From Habari Project

Jump to: navigation, search
  • We need to add what we expect from a major release.
  • When do we stop supporting previous versions? When we release 2.0 should we stop maintaining any of the 1 series releases?

michaeltwofish 00:50, 17 March 2008 (UTC)

My suggestion: Major version numbers have incompatible APIs. We maintain the last major point version of the last two major versions. So if we're at 7.3, then we also support 6.5, if there is no 6.6. At that point we would not support any of 5.x, no version of 6.x prior to 6.5, and no version of 7.x prior to 7.3. Users would be expected to upgrade to the latest version of the major version they're using, since our "maintenence" will consist of applying changes as a new major or minor point release. --ringmaster 01:06, 17 March 2008 (UTC)

  • Define what is a "critical" bug. freakerz 01:10, 17 March 2008 (UTC)

I agree with ringmaster. In my mind the breakdown is that major releases are essentially new software as a whole. Points are new versions of the major release and point-point releases are bugfix only. Morydd 01:11, 17 March 2008 (UTC)

That sounds reasonable too. I'll update the page as such. --michaeltwofish 01:23, 17 March 2008 (UTC)

Issues that should be addressed by this page

  • information about plugins and themes in -extras, specifically what should be done with tagging and testing.
  • marking milestones on trac tickets, specifically in relation to freezing releases
  • a diagram or video explaining the branching policy
  • upgrade documentation

Security issues

We don't currently have a full process for reporting and fixing security issues (such as fixing exploitable bugs in a private repository rather than in the publicly visible one, so that the issue is less likely to be exploited in the wild while being tested in a makaanga). Once we do, the description of minor point releases should be updated to reflect it.

Personal tools