[Bioperl-l] Bioperl 1.0alpha

[Jason Stajich]

On Mon, 18 Feb 2002, Ewan Birney wrote:

>
>
> As mentioned earlier I have tar balled up Bioperl 1.0 alpha. It is
> available at
>
>   ftp://bio.perl.org/pub/DIST/
>
> as
>
>   bioperl-1.0.alpha.tar.gz
>
>
>
> The main reason for the version numbering change is just to emphasise to
> everyone that we are *serious* about releasing 1.0. At this point our main
> focus should be documentation --- there are still some cornors to the code
> that need cleaning out --- I suspect alot of this will be sorted out in
> the second hackathon (Cape Town) where Jason, Heikki and I can bash on it
> (or probably more correctly on the plane to Cape Town, assumming we don't
> get knee-capped on the plane.
>
>
>
>
> Many thanks to Brian Osborne and Peter Schattner for updating/reviewing
> the documentation, especially from the perspective of the new comer. I
> feel the first introduction documentation looks really good. Can other
> people check this out?
>
Ditto!  I also started the FAQ to address some typical questions that come
up.  Please add more to it if you have any good suggestions.

>
>
> So --- outstanding jobs in my view
>
>   (a) write Bio::SearchIO::Writer::html so we can shoot Bio::Tools::Blast
> (sorry Steve).
>
>   (b) Review by people who should be reviewing.. (!) Doh!
>
uh, heh.  Yah.
Here is the basic gist of what I am concerned about:
I'm still a little concerned about seqfeatures that should
be expanded versus the Split Location model.  This is basically when
someone calls:
$feat->add_sub_SeqFeature($subfeat,'EXPAND');

So with the invention of the Bio::Location::Split system for handling
multiple locations, so I'm not sure we do the right thing for locations
versus sub features.  Gotta dig some more and come up with appropriate
tests.

This also relates to working with locations and when we call trim on a
sequence and need to renumber the coordinates for the features on the
subsequence.  Need to develop the tests for this so we can be sure we're
really acting properly (pretty sure we're not).

>
>
> Then - branch
>
>    - on release, list of modules to prune - I think
> Bio::Tools::SwissProtParser should go, as it is really waiting for an
> event based SeqIO framework (now... that is going to be a real shakeup -
> *definitely* not 1.0 stuff).
>
Okay - let's also remove
Bio::Tools::Fasta (there is no test for this and it is replaced by
                   Bio::SearchIO)

Not sure if we want to release with the Biblio objects included?
Should we remove from a 1.0 branch?

>
>
> Should we be releasing just bioperl-live as the 1.0 release or
> bioperl-all? If so, how much do we need to cross check bioperl-all? Yadda,
> yadda. This could get complex!
>
db has certainly been cross-checked against 1.0 (although it is probably
going to be in flux till at least the hackathon if not later).

The gui was tested with Mark's stuff (ignoring the MapViewer code I dumped
in there from a contributor).

ext is not part of the bioperl_all since we have
been talking about phasing it out - but perhaps it should be?

The CORBA code *should* be in working order by the end of the hackathon
... sooo I say let's try for the whole thing.


>
>
> -----------------------------------------------------------------
> Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
> <birney@ebi.ac.uk>.
> -----------------------------------------------------------------
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
>

-- 
Jason Stajich
Duke University
jason@cgt.mc.duke.edu