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" <[EMAIL PROTECTED]> To: "'Boost mailing list'" <[EMAIL PROTECTED]> Sent: Tuesday, July 15, 2003 3:09 PM Subject: RE: [boost] Re: plans for a bugfix release ? > > David Abrahams wrote: > > > Beman Dawes <[EMAIL PROTECTED]> 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 > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost