Re: [Statcvs-users] Release early and often?

[Brian G. P. <br...@br...>]

I am an active developer/manager in many open source projects, and have used 
StatCVS for several years/versions.  So, my comments come from this 
perspective.

On Wednesday 23 March 2005 03:54 pm, Richard Cyganiak wrote:
> So what can I do to improve the release process?

I'd Start with nightly builds.  I find that these often allow people who can't 
or won't build the software themselves to test new features as they make it 
into CVS.

If you have JUnit tests for StatCVS, place a link to the test results on the 
same page as the nightly build tarball.  This communicates to developers and 
users what the potential state of the code is without requiring constant 
effort on your part.

> Publish release candidates?
> Offer a stable and a beta download?

My usual approach is to publish a release candidate when the development team 
thinks the code is ready for release, and usually allow a few days for 
testing.  People are generally quite responsive to calls for testing a 
release candidate.  I don't maintain a separate branch in CVS for the release 
candidate, as the entire process usually only takes a few days.

This is a little different on a large project like Squirrelmail.  The 
Squirrelmail development is *always* split into Stable and Development 
branches, and changes are merged back to stable form development.  StatCVS 
does not seem to be a large enough project to require the level of effort 
that goes with maintaining two separate CVS branches.

> Just stop worrying about bugs and release without much testing?

Nightly builds with a test process will find a lot of bugs (though not all of 
them!)

> What do you think? How should an open source release process for a
> project like StatCVS work? Both developer's and user's point of views
> are welcome.

Thanks for the great software!  I rely on it to keep an eye on what the 
development team is doing across multiple projects.  StatCVS has been a great 
help to me, keep it up!

Regards,

   - Brian