Release Mismanagement How to Alienate Users and Frustrate Developers - - PowerPoint PPT Presentation

Release Mismanagement

How to Alienate Users and Frustrate Developers Hyrum K. Wright

The University of Texas at Austin

1 Thursday, July 23, 2009

Motivation: Subversion 1.5

Release Branch Date Release Date Days to first RC Number

• f RCs

Days to Release Days from previous release 1.0 19 Dec 2003 23 Feb 2004 63 1 66 N/A 1.1 10 Jul 2004 29 Sep 2004 4 4 81 219 1.2 4 Apr 2005 21 May 2005 1 4 47 234 1.3 28 Sep 2005 30 Dec 2005 7 7 93 223 1.4 5 May 2006 10 Sep 2006 27 5 128 254 1.5 30 Jan 2008 19 Jun 2008 69 11 141 648 1.6 16 Feb 2009 20 Mar 2009 4 32 274

2 Thursday, July 23, 2009

Postulate

Unreleased software is nonexistent software

3 Thursday, July 23, 2009

Corollary

Every (relevant) project needs to release software

4 Thursday, July 23, 2009

Definition of a Release

Tarball uploaded to FTP server Package management system package Self-contained installer Web service deployment (Insert your release artifact here)

5 Thursday, July 23, 2009

How to Alienate Users and Frustrate Developers

6 Thursday, July 23, 2009

Constantly vary the release process

Consistent process reduces confusion among users and developers Document, document, document A consistent process allows for a large amount of automation and scripting

7 Thursday, July 23, 2009

Don’t put somebody in charge

Releases are cathedrals You projects needs to have a core person or team who

• versees the release

The “release manager” or “release team” The amount of power you give this person can vary, but somebody has to be accountable

8 Thursday, July 23, 2009

Use random version numbers

Release numbers communicate information Define what intermediate numbers mean What is a release candidate? alpha? beta? gamma? Who can remember 0.99.1.234-j34_beta1 anyway?

9 Thursday, July 23, 2009

Monolithic releases are good

Large features create large releases and long time periods between releases Stabilization times and costs increase The bigger the feature, the fewer people understand it Be careful about defining releases with features FreeBSD 5.0

10 Thursday, July 23, 2009

Release schedules are unimportant

Schedules and roadmaps communicate with users, including packagers and maintainers While they can be flexible, schedules help manage user and developer expectations “When will my feature be released?” “When will my bug be fixed?” Time-based releases require developer discipline

11 Thursday, July 23, 2009

Disregard third parties

API consumers and packagers can find bugs not exposed by “normal usage” It’s better to find and fix these bugs early in the release cycle than later Keeping third parties “in the loop” fosters a sense of community

12 Thursday, July 23, 2009

Users = Testers

Don’t rely on users as testers Do stringent internal testing as part of the development process Increase your testing toward release Aggressively publish pre-releases to encourage wide- spread testing

13 Thursday, July 23, 2009

Ensure large amounts of time between releases

Large periods between releases discourage users who want new features and bug fixes Large periods between releases discourage developers who want to see their code release (Often, these are the same group of people)

14 Thursday, July 23, 2009

Make releases difficult to find

Release artifacts should be posted in an easy-to- discover place on your project website Only 1 or 2 clicks deep Release notes, change logs and other release docs should be easily found also Don’t write half-baked release notes

15 Thursday, July 23, 2009

In Summary...

Releases are the product of your project, and a primary method of interfacing with your users Establish a pattern and follow it Less surprise the better Effective communication key Within developer community Between developers and users

16 Thursday, July 23, 2009

Thanks

hyrum@hyrumwright.org

17 Thursday, July 23, 2009