Although probably indirectly touched in ExtremeProgrammingChallengeTwenty, I still find myself struggling how to fit parallel releases into the PlanningGame. Typically, the deliverable of a release (ProductVersion or ProjectRelease) ends up in the customers production or test environment. Developers are already busy on the next release, before defects in the previous release are reported.
	* How do I plan the patching of a previous release in light of the fact that we already started the next one? Note: It seems hardly appropriate to schedule the defect UserStory and patching EngineeringTask in an Iteration of the current Release.
	* Do releases need to be sequential?
	* Do releases correlate to a version of a product?
YvesReynhout
----
''One crazy answer ...''

Always ship the latest version; never ship a patch on a previous version. Don't branch the code.

You're doing extensive testing, which means that you have very few defects and probably no showstoppers, which means you probably don't have to patch.

If you do have to patch, you're doing continuous integration, so you just put the bug fix in the current version and ship that. It's better than the previous version in every respect, since your tests show you that you have no regressions and you have just fixed one defect.

But what if there are new features in the new version and you don't want to ship them? Well, (a), you probably should ship them, because it will increase the value of your software. But (b) if you don't want to ship them, put a feature in that turns them off, then ship the current version.

--RonJeffries

Quite the crazy answer - put in a feature that disables the new feature.  I may have to use that.

''Maybe InRealLife you don't want to ship the new features for the very simple reason that your customer hasn't yet paid for them.''
----
See ExtremeProgrammingChallenge