Release Mismanagement How to Alienate Users and Frustrate Developers Hyrum K. Wright The University of Texas at Austin Thursday, July 23, 2009 1
Motivation: Subversion 1.5 Days Days from Number Days to Release Branch Date Release Date to first previous of RCs Release RC 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 0 4 32 274 Thursday, July 23, 2009 2
Postulate Unreleased software is nonexistent software Thursday, July 23, 2009 3
Corollary Every (relevant) project needs to release software Thursday, July 23, 2009 4
Definition of a Release Tarball uploaded to FTP server Package management system package Self-contained installer Web service deployment (Insert your release artifact here) Thursday, July 23, 2009 5
How to Alienate Users and Frustrate Developers Thursday, July 23, 2009 6
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 Thursday, July 23, 2009 7
Don’t put somebody in charge Releases are cathedrals You projects needs to have a core person or team who oversees the release The “release manager” or “release team” The amount of power you give this person can vary, but somebody has to be accountable Thursday, July 23, 2009 8
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? Thursday, July 23, 2009 9
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 Thursday, July 23, 2009 10
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 Thursday, July 23, 2009 11
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 Thursday, July 23, 2009 12
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 Thursday, July 23, 2009 13
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) Thursday, July 23, 2009 14
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 Thursday, July 23, 2009 15
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 Thursday, July 23, 2009 16
Thanks hyrum@hyrumwright.org Thursday, July 23, 2009 17
Recommend
More recommend
