Re: [boost] Re: plans for a bugfix release ?

From: Ben Woodhead (zander_at_[hidden])
Date: 2003-07-15 16:42:01

Hello..

Typically what i do for releases is something along the line of this.
prject - x,yy,zz

x - major architecture changes.
yy - minor changes. (uneven for development).
zz - no interface changes. bug fixes.

I try to release the zz often (for stable). Everytime there is a critical
fix or a few bug fixes that are causing people problems.

For the unstable versions i try to release as soon as there are some cool
features in there that need testing. If things go really well on an unstable
release and the features that we want are in then i consider a new stable
version.

Rember the release early and often. The longer its being developed in cvs
the more bugs that are going to be around during a stable release.

I personnaly don't like the major release scheduals for anything other then
major releases. Anything that is going to take 6 months to a year should be
a major release. Minors are like once a month.. And patchs as soon as there
is enough problems to require one.

Ben

----- Original Message ----- 
From: "Rozental, Gennadiy" <gennadiy.rozental_at_[hidden]>
To: "'Boost mailing list'" <boost_at_[hidden]>
Sent: Tuesday, July 15, 2003 3:09 PM
Subject: RE: [boost] Re: plans for a bugfix release ?

> > David Abrahams wrote:
> > > Beman Dawes <bdawes_at_[hidden]> writes:
> > >
> > > When we released 1.30.0, despite extensive pre-release testing, it
> > > went out with several prominent showstopper bugs.  Don't you think
> > > we'll make the same mistake for 1.31.0?  Also, AFAICT 1.30.1 can go
> > > out much, much sooner.
> > >
> >
> > I agree with Dave here. To me there is another good reason for doing
> > minor releases more frequently. Neither the next major
> > release nor the
> > CVS state is likely to help most of the people who use Boost in their
> > projects.
>
> I agree that we should publish patch releases more frequently. But the
> question here what is the criteria whether the release should be
considered
> patch or next one. In my projects I choose the following strategy: if
> release does not affect the interface, so that I could simply substitute
one
> shared library with patched one - this is patch release. In other case
it's
> next release. It may be a little different with boost, cause most of the
> staff in the headers. But the idea should be IMO similar.
>
>
> > I guess that there are a lot of projects out there that
> > cannot allow for
> > an interface change in one of the core libs every couple of month. So
> > they really need bugfix only releases if showstopper bugs are
> > found in
> > the last release.
>
> We should've publish patch release right after we discovered them. IMO at
> this point, with all those iterator adaptor changes I would rather made
new
> release.
>
> > Just my 2c
> >
> > Thomas
>
> Gennadiy.
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>