[vtk-developers] announce: vtk 6.2.0 release candidate 1 is ready

[Marcus D. Hanwell]

On Thu, Feb 19, 2015 at 4:25 PM, Sean McBride <sean at rogue-research.com> wrote:
> On Thu, 19 Feb 2015 15:16:54 -0500, David E DeMarle said:
>
>>Aiming for an rc each Monday. The number of rcs depends on the severity of
>>things that people find.
>>
>>So far Ben and I have our eyes on three topics, none of which are severe.
>>Most likely those will fold into release tonight and become 6.2.0 final
>>come Monday. If something else turns up we'll do rc2 then instead and
>>reevaluate later next week.
>>
>>Patch releases are not time consuming, so if something slips through we'll
>>do a patch release in a month or so.
>
> That seems awfully fast. :(
>
> Isn't the goal of a release candidate phase to give a chance for people to test before releasing a dud?  7 days is pretty short.  Releasing a dud and requiring a 6.2.1 a couple of days later would look bad.
>
> Personally, I'd prefer to see something like ITK or CMake or llvm, which release a few rc's over a few weeks.  ex: searching my email history:
>
> 2014-12-08  ITK 4.7rc1
> 2014-12-16  ITK 4.7rc2
> 2014-12-19  ITK 4.7
>
> Taking my own case: rc1 announced Monday, Tuesday I had time to build it, Wednesday I tested a little, today I merged into our build process, tonight's nightly will include it, and only tomorrow will our QA take a crack at it.

It isn't that short, and we know not everyone will get time to test
the RCs. Frankly I have seen plenty of releases with extended RC
cycles, only to discover a critical issue days after release and make
a prompt bug fix release. Why make more than one RC if there are no
critical flaws discovered? It looks like ITK might have rolled a final
in 8 days had they not had to make a second RC.

If you have feedback we would welcome it, Monday is still a ways off
and it sounds like you will have the RC with QA tomorrow. We do a lot
of QA continuously, and test with various projects based upon VTK too.

Marcus