[Bioperl-l] Splitting Bioperl and Test related Suggestions
cjfields at uiuc.edu
Thu Jul 5 10:33:46 EDT 2007
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
>>> expectation that each dev release is supposed to have all bugs
>>> 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
>>> 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.
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.
More information about the Bioperl-l