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

[Jukka U. <juk...@dn...>]

Richard Cyganiak wrote:
> Hi Jukka,
> 
> Thanks for the thoughtful response! Responses/questions inline.
> 

Hi,

some comments below ...


> Am 24.03.2005 um 21:40 schrieb Jukka Uusisalo:
> [...]
> 
>> How about process as follows:
>>
>> 1. Decide what new features are in next release
>>
>> 2. Provide nightly-build. Nightly-build is released from cvs head 
>> branch if there are any changes in cvs, code gets compiled and passes 
>> unit tests.
>>
>> 3. When all features in next release are implemented, provide 
>> release-candidate. This point there should be branch in cvs for release-
>> candidate bugfixes. Propably you will need couple of release-candidates.
>>
>> 4. When you think release-candidate is stable enough, just release 
>> official release or maybe uses take a vote, but propably everybody 
>> will use some release candidate as production at this point.
> 
> 
> I think I'd rather skip #1. StatCVS contributions (including my own) 
> come from people scratching an itch, and it's kind of hard to plan that. 
> So I'd rather just wait until there's enough new stuff.
>

But if we talking about short and small releases, why we have to wait?
If there are some new stuff, you can make release plan like at this
moment release plan would be just, next release supports tags.

Release plan does not have to be detailed list of all coming changes or 
bugfixes, just major issues of next release.


> Having a release candidate branch seems like a good idea. This means 
> work on new stuff can continue while the candidate matures.
> 
> Any guesses how long we might have to stay in RC mode before the 
> candidate is well-tested enough?
> 
> Also, is it worth the trouble for such a small project? I don't want to 
> spend much time managing the process.
> 

If you look statcvs cvs activity, release candidates may be wortless.
If there are nightly-build available and new commits haven't done to
cvs and no new bugs are not reported, what we need more for "official" 
release. ;)

> 
>> Nighly-builds requires automated build system and good enough unit test
>> cases. Do you have checked coverage of unit tests?
> 
> 
> I like the idea of nightly builds. Get the new stuff out as fast as 
> possible.
> 
> Our test coverage is not too good, especially in the HTML output code. 
> But I wouldn't worry about that too much, the most important parts are 
> well-tested. I believe that nightly builds would drive test quality 
> because we would actually rely on the tests.
> 
> Any recommendations for a test coverage tool? (I guess the answer will 
> have something to do with Maven :-)
> 

I just played little bit with Clover. They will give free licenses to
open source projects. But i just played, nothing any serious. First 
impressions are pretty good.


- Jukka -