Release (Planning) Strategies

Strategies for release

cassandra worked on major & pt releases. "done when it's done" frustrates people at midpoints because it's always broken. every 6 month sprints better b/c it skips features in favour of bug fixes

feature based suffers from scope creep (adding features to features). Time intervals mean people only need to wait another N time.

open source goal: release often. But when you release too frequently it's also jolting.

feature based might work if it's done frequently enough. ( If you can guarantee features get released timely ) but if you can't, time based is better, can coordinate on dates better. Useful especially with things that are cadenceed on other people ( ubuntu & gnome, eg )

Predictable schedules help people plan. Life might be hell for a week at some point. libc6 & debian rebuilding everything.

Nobody wants to release buggy software, but sometimes there's the reality that you need to commit to a date, and if the bugs can't get fixed, release anyways. Accept reality. (blocker vs. nonblocker)

On similar projects with different cadences ( ubuntu & debian ) the first will often find bugs. Ubuntu's samba bug informed debian.

need good release management to prioritize blockers & nonblockers.

For essential features, good release mgmnt needs to watch them closely. Either it'll get done, or maybe it wasn't that essential. (There's nothing you can't wait another 6mo for) If it's mission critical, do it first.

feature-based releases: sometimes ideas will come along midcycle. Do you add it halfassed now, or do you wait an indefinite amount of time for the next release and get it in there?

People are attracted to feature based, because it gives you a view to the future but that's probably wrong. No way to guarantee it anyways because you don't control all your contributors.

Can plan time based releases really well ( QA, documentation, etc )

feature based releases are an artifact of proprietary software ( marketing and product collect requirements, eng has to build it ) but at the end of the day, the ones doing the work decide what goes in.

feature-based is also artifact of hardware ( you can't do capacity planning, mfring when you don't know what you're going to build. Nothing gets added midstream )

when to support ? Openstack does version - 1, unless someone really cares. ( patches for two releases back )

open source is like polishing a stone, it always gets more polished. features start small & grow in scope as time goes on. But sometimes it's like breaking a piece off & it's disruptive. ( but you don't get diamonds, which have to be cut )

Time based releases: big innovations can just happen, but with feature based releases you need to plan in advance

samba was waiting for a feature before samba4, but that took 5 years. Samba3 was growing with time based releases, and grew to include a lot of the features of 4.

the only reason you'd do feature based releases is if your marketing wants to make a big splash with a new feature. Press asks "what's coming up in the next release" but there's no way to really do that. Marketing needs to change to come up w/ marketing materials closer to releases

even marketing tends to appreciate time based releases. because they can get their messaging together in time ( there's still a lag between feature freeze and when QA & website is done )

mgmt is always asking 'when is my feature done' ? But if they want the feature done, hire someone.

Distros building on top of your stuff has a different opinion ( they want particular features ) but they can just wait. If it's that valuable, hire someone.

What about contentious features ? Cassandra almost forked becaues of it. There's no real answer.

Time based is really the only solution if you've got a distributed community, but a single company has an easier time of doing feature based ( since they control all or most devs. )

New products should release early ( more like aglie ) rather than long cadences ( 6 months, etc ). Long cadences are a sign of maturity.

Who makes the release plan? BDFL, or a grassroots thing, or customers.

Apache has PMC's that make the decision.

Openstack has design summits every 6mo, contributors come & talk about what they're going to work on the next 6mo. People assign themselves to various things, etc. but plans are open to change. Release manager tracks things & makes sure they get done. At some point there's a feature freeze. 50% miss rate on features proposed in the summit. 1.5month milestones between releases.

Milestones are a good way to impress a timeline on developers.

Fedora has devs propose features, which goes to comittee that votes 'yes' or 'improve'. Date by which features need to be advertized. Feature freeze is where they all need to be in but not necessarily bugfree. If they aren't complete by beta, they get removed. Has been solid for 4-5 years.

Community leader needs to harass people close to feature freeze & remind people of the schedule.

Release manager is a lot more like 'cycle manager', release itself doesn't take much time, mostly has to harass people midcycle

People will often reinvent all the wheels and need to be made aware of the schedule, how to break down their wheel invention.

Learning to say no is important. When a feature is almost there on feature freeze, you need to say no & bump it to the next release. Documentation, etc needs to be up to snuff, it takes time.

You can use advertising to impose schedules on upstream ( you will get more marketing if you get it done by date X which is our feature freeze )

Mature distros do about 6months, smaller projects might do 3-4. More than 6months is too long. Really solid release process lets you have earlier ones ( jenkins does a couple weeks ) Makes documentation really easy with short cycles. QA is harder.

release too often and people don't care, and don't want to do QA.

Openstack point releases are bugfixes & security things. Midpoint between releases.

Big problem with proprietary releases, people keep secrets.

Marketing needs to understand that having a product regularly is itself a feature. Customers can expect a release every 6 months with some number of features, but they aren't waiting on a particular feature.

Still falls down with embedded stuff / hardware. You need to take all the stuff in embedded. But you can do it with a yearly release cycle with a really long feature freeze.

Continuous releases might be better, if you can codify your process such that you only merge in changes that are done ( using branches, etc. )

Ultimately, the question is "what is a release", is it the marketing, or features, or ?.

Continuous releasing is hard for newcomers, because they don't know what's expected of them and when.

Jez Humble from Thoughtworks, gave a talk on Continuous Delivery at JAXConf San Francisco last week (Tuesday, July 10, 2012)