Task Team for Software Releases

This topic describes the release task team. The process followed by this team is described in ReleaseProcess.

Goals

• Customer focused features
• Efficient process to handle new features from proposal to implementation
• Focused on mission, quality and performance

Tasks

• Plan and Coordinate next major/minor release. Decision of release plans are done with the board of the Foswiki association.
• Plan and communicate important milestones such as
  • Feature Freeze
  • Code Freeze
  • Branch from trunk to release branch
  • String freeze
  • Beta releases
  • Release candidate releases
  • Final release
• Maintain ReleasePlan
• Delegate responsibility when unavailable
• Monitor feature proposals.
  • Maintain the ReleaseProcess
  • Ensure that the proposal has a committed driver that will implement it if accepted.
  • Ensure that the proposal when committed also has a date of commitment which is not in the past.
  • Ensure the proposals are visible in the 14-day rule searches on FeatureProposals for at least the 14-days
  • Note if concern has been raised.
  • Follow the discussions and see if consensus is reached.
  • If discussion stops without a result decide try to trigger the community to end the discussion
  • If no consensus is reached bring forward features with proposals to a community vote
• Authorise fixes (patches, or inter-release update packages)
• Decide and Create the patch releases as required
  • When very severe bugs are found shortly after a release
  • When a level 1 or 2 security issue is found that requires a fast release
  • When the number of bugs has pilled up to a level that justifies a release. Listen to the community and release patch when there is a general wish in the community to have one.
• Create upgrade package that can be applied to any previous release within same major/minor tree
  • Upgrade package containing all files minor/major release (last decimal 0 in release number) except a short list of files that admins normally tailor.
    • Ensuring that upgrade package can be applied to a production site with almost no downtime to fix things.
    • Excluding files that may have been updated but changes are not necessary and would make the upgrade less easy.
• Recruit and coach the CustomerAdvocates who are members of the community that represent the end users more than the developers.

Help Wanted

• We need more people acting as CustomerAdvocates
• More needed

Scope

• Normally running from minor/major to next minor/major release
• DebianPackagingTaskTeam is outside the scope but we communicate via the normal channels (mailing list, IRC, foswiki.org) so the debian team knows when the release is coming.

Updates

I (Kenneth) do not see myself having power. I am secretary that coordinate and suggests releases. Those releases that I have "dictated" have been security related patch releases and not planned releases.

I believe the right thing is to redefine this team again and I will take a stab at this trying to describe what we have and describe my own role (assuming that noone currently have a desire to do what I do).

I will gladly continue my role as release manager. I am not a great programmer. I am a project manager by skill. And I think I can best serve the project in this role. Some of the old description above is a lot about power. I do not see my role as a power role. I am a secretary that tries to keep an overview of the releases, does many practical things, and reminds people about "misc stuff" so everything gets done.

The specialized releases like debian etc are normally coordinated. But with the security initiated releases I do not have a good answer to how to coordinate this and at the same time keep things secret while developers are looking for a fix. Suggestions welcome. In practical life people have responded fast after I release but maybe a simple email notification to a short list of special release maintainers that I send 2 days before a security release is what is required. For regular releases the public release plan should be shouted out to everyone all the time.

Decisions of releases of major and minor releases are best taken by the board of the association and this is what has happened with 1.1.0.

Latest update is that we now have a release plan that was agreed at the early March board meeting. See ReleasePlan.

It has also been announced on foswiki-discuss mailing list.

-- KennethLavrsen - 11 Mar 2010

Kenneth and George are currently the main driving forces coordinating new Foswiki releases.

-- MichaelDaum - 11 Jun 2012

I have taken over the role of the release manager. Next release will be 2.1.7, hopefully in time with 12th Foswiki anniversary.

-- MichaelDaum - 07 Nov 2020

Commenting is disabled while not logged in