Michael,

It may be typical but that doesn't mean it is optimal. It may well be
for your situation, I don't have a clue. For us though, we released a
new product on Nov 20 of last year and have released 8 times since then
and have another release coming out this week. For us it doesn't make
sense to ship a patch... we just tell them to download the latest build.

In the event we ship a critical bug and absolutely *must* ship out a bug
fix immediately, we tag at every release and we can go back and fix the
bug on the tag and reship that version if necessary.

Ultimately our goal (admittedly not quite realistic yet) is weekly
releases. 8 releases in 5 months is good but not quite as good as we
want. At CITCON (Continuous Integration and Testing Conference) in
Denver a few weeks ago, we had a session on whether or not a daily
release was a good idea. Andrew Binstock pointed out some of the
concerns you have as well as the "over the wall" user testing that is
required by some laws that might make it impractical or even impossible.
Paul Duval pointed out that with continuous integration it might not be
a bad goal to be *able* to ship every day, even if you don't. In any
case, daily is probably a bit extreme... or maybe not.

Incidentally our frequent releases are on a brand new product, we also
have a more mature product that is not as actively developed with new
features but which we try to keep in a similar state so that it is
shippable as soon as new features are added. Occassionally we have had
to go back on a tag / branch and do a bug fix but we try to avoid that.
Our goal is to keep the trunk in good enough shape to ship at the drop
of a hat... and we provide the hat.

Matt


--- In extremeprogramming@yahoogroups.com, "Michael Dubakov"
<firefalcon@...> wrote:
>
> The situation is absolutely typical for product development.
> If you have a product, you have to release patches and developing new
> version.
>
> Release itself has some related activities like web site updates, PR
> buzz and so on. So for example weekly releases will not work.
>
> BTW, in our company we do not have parallel releases (I mean in plan,
> with dedicated developers, etc).
>
> Michael Dubakov
> http://www.targetprocess.com
>
> > Are you dealing with "shrink wrapped" software such that "releasing"
is
> > more painful than simply uploading the latest release to your
server?
> > If so I can see the value of having distinct releases but otherwise
I am
> > not seeing the logic of maintaining multiple releases
simultaneously.
> > Curious about the situation you are dealing with.
> >
> > Matt
> >
>