There are two sides to the problem - one is architectural, and one is
process oriented. Your blog post speaks more to the process. When we
have encountered this, we have simply included the work in our sprint
backlogs, in a way that is planned to achieve the necessary release
schedule. Fixes are more difficult - we tried various things, but for
us it turned out to be best to have the fixes as another part of the
sprint backlog. I think each team has to find its own way though.

It was difficult to achieve all required deadlines in this scenario.
The reason is that there was simply too much work for a small team -
we were over-committed.

For the rest, I'll speak to the architectural side:

Unless v3 is a rewrite, it is probably defined as a new component, or
a major improvement of an existing component. In any case, it is ok
to branch *just* that component, and keep more common code...in
common. Automated builds can take care of bringing the right code
together for the right versions.

If possible, *don't branch at all* and develop v2 and v3 on the same
code-branch (you can still branch v1 of course). This can be achieved
with a simple "switch", that is turned on for v3 and off for v2. It
can be a compiler switch, but I prefer something external to the code,
such as a setting in a db table. In my own environment, we call these
switches "feature keys", because they turn on features.

Some large distributed deployments (ebay) make use of this idea to
simplify the deployment process - deploy in v2 mode, then throw the v3
switch when you're ready to activate the features. If things aren't
working out, reset the switch to v2 and try again next week.


~Steve

On Wed, Apr 16, 2008 at 2:51 AM, Michael Dubakov <firefalcon@...> wrote:
>
>
>
>
>
>
> I think this question is not highlighted in books, articles and blogs. I did
> not find any
> comprehensive article. However the problem is pretty common. Team
> developing main
> release line (v.2), support release (v.1.x) line and future release line
> (v.3) in parallel. What do
> you think about that? How that should be handled in a single team?
>
> Starting point may be this post
>
>
>
http://www.targetprocess.com/blog/2008/04/should-we-have-parallel-releases-and.h\
tml
>
>



--
Steve Campbell
http://blog.perfectapi.com/