[Bioperl-l] moving Bio::Tools::Run, 1.1 release plans

[Jason Stajich]

Here are the plans regarding splitting the Bio::Tools::Run subdir off into
its own cvs repository.

In order to preserve all of the history for Bio::Tools::Run and not
break the past branches, I will plan to lift the whole directory into a
new cvs module called bioperl-run.  When releases are done we'll be sure
and bring this back in as well as I'll add it to the cvs alias
(bioperl_all) which will make a directory called 'run'.  Once we are
confident that this works I will then plan to 'cvs remove' all the files
in bioperl-live/Bio/Tools/Run.  Now it is important before we start the
move that everyone commit all of their project files in the Bio/Tools/Run
directory or else you'll need to checkout the new bioperl-run module and
copy your working files over.  I'm going to say that Tuesday is the day
for the move -speak up if that is a problem.  You'll need to have all of
your changes checked in, or you'll need to handle making a fresh checkout
and copying your changes over to the directory structure.

This copy + cvs remove in bioperl-live will allow the older branches to
work so we don't have to worry about pulling out old versions.  It will
continue to eat up disk space, but I think with the new server coming
online by Aug 1 (fingers crossed) we should be quite fine.  Along those
lines, Chris please let us know what the timeline looks like for the move
to the new developer-only box so we can start to plan for this.


1.1 release
-----------
I would like to plan on putting out a developer release of bioperl (1.1)
before BOSC, so in the next 2-3 weeks depending on the outstanding
projects.  There are a bunch of changes and bug fixes on the trunk that
aren't on the branch including the Pise, PAML, RepeatMasker, and TRIBE
wrappers.  I was informed of, and fixed, some bugs in the SearchIO FastA
parser. There is also the new SeqFeature::Collection object to handle
storage of lots of SequenceFeatures and fast retrieval of subsets defined
by location.  Hopefully will have it implement part of the DasI interface.

I'm also changing the object creation model for the Bio::SearchIO parsers
so it is factory based to facilitate implementing the hmmer parser and
other classes that will get written.  This is very much in the spirit that
SteveC defined for his psiblast + statemachine but the API is little
different.

It would be great to get the coordinate mapper that Heikki has described
in.  I've also not been able to work on the
FeatureAggregator/SemanticMapper as of late, but don't let me initial
proposal to work on it keep anyone away from taking a stab at it.  I hope
to get back to it soon if no one else does want to work on it.

-jason

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