[Bioperl-l] Splitting Bioperl and Test related Suggestions

[Chris Fields]

On Jul 5, 2007, at 8:07 AM, Hilmar Lapp wrote:

> On Jul 5, 2007, at 4:09 AM, Nathan S. Haigh wrote:
>
>> Chris Fields wrote:
>>> I think what's partially responsible for slowing down releases is  
>>> the
>>> expectation that each dev release is supposed to have all bugs  
>>> fixed,
>>> work for every OS, etc.  In other words, act like a stable release.
>
> It doesn't. A stable release has a stable API that will be  
> supported until the next stable release through point releases.

I agree, but I think there is still an expectation that 1.5.2 and  
beyond are more like true 'stable' releases even though we still  
designate them as 'developer.'   We unfortunately reinforce that when  
we tell users they need to update to v. 1.5.2 or bioperl-live to fix  
a particular bug in the 1.4 release.

There's nothing we can do about that now (hindsight is always 20/20,  
and 1.4 is just too old).  We (pumpkin, core devs) can try correcting  
that by ensuring any bug fixes be committed to any new stable branch  
as well as to live, at least until it becomes too problematic to  
maintain that particular stable branch (at which point we would go  
about getting ready for the next 'stable' and repeat the cycle over  
again).

>>> A developer release by nature is living on the edge, so why not have
>>> regular dev releases?
>
> There's no problem with regular dev releases, but tests will need  
> to pass. There was never a stipulation that all bugs need to have  
> been fixed. But all tests need to pass, so in an ideal world (in  
> which everything is being tested) all tests passing would imply all  
> (known) bugs fixed. Obviously, we don't live in an ideal world ...

...particularly when it comes to network-related tests and remote  
server problems (but those are by default not run, so there is a way  
around test fails there).  I agree here as well (all tests must  
pass).  As for the bug fixes, we can just stipulate which ones were  
fixed with the release (in a RELEASE_NOTES or similar), and maybe  
have TODO's in the test suite designating they are being worked on.

Basically, at regular intervals, maybe with a few weeks of lead time,  
the pumpkin would announce an impending dev. release.  Go through  
rounds of tests, bug fixes, etc.  When all tests pass post it on CPAN  
as a dev. release.  If we have a stable release branch with relevant  
bug fixes we can post that as well, again to the point where it  
becomes too problematic.

Would we just take a snapshot of MAIN and any relevant stable branch  
at that particular point for the CPAN release, just increasing the  
version number (1.x.y)?  Would it make sense to have a 1.x.y branch  
for each release (I don't think so, but maybe others disagree)?

> If not everything passes then what is the big difference to a code  
> snapshot? If using cvs (or svn) is too difficult for most people,  
> we can consider creating a mechanism that puts up nightly snapshots  
> for download.

If we feel a nightly snapshot is warranted we could do that though.   
I personally don't think there is a need, particularly since we have  
several means to obtain the latest code at any point in time  
(including the browsable CVS 'Download tarball').  We could state the  
next dev/stable CPAN release (pending on date dd/mm/yy) will have the  
bug fix, and if they want it immediately then pick it up from CVS.

>> -- snip --
>>
>> I agree, although would the dev releases still need to pass all the
>> tests? I'm thinking of people installing via CPAN.
>
> For example, that's another point.
>
>  	-hilmar

Yes, I agree.

As an aside, I don't think dev. releases pop up when you run a simple  
'install Foo::Bar' from the CPAN shell but I'm not sure; Sendu may  
know the answer to that.

chris