[Bioperl-l] Splits again
bix at sendu.me.uk
Wed Jun 27 18:43:48 EDT 2007
Chris Fields wrote:
> On Jun 27, 2007, at 4:05 PM, Sendu Bala wrote:
>> But the main problem with this approach is that maintenance, global-
>> style code improvements and releases become a nightmare. I could,
>> perhaps, imagine a scenario where the repository stayed as-is (one
>> monolithic collection), but the dist action of Build.PL could be
>> altered to generate a release package per module instead of one big
>> release package of all modules, as is currently the case.
>> Is there much value in doing that? Does anyone want me to look into
>> the feasibility of such a thing?
> Not for the time being, at least in my opinion. Too much on our
> plate at this point with svn migration, test conversion, bugzilla
> running over (next point of attack!), etc. Maybe something to think
> about after, though I like the idea of a few splits to core as Steve
> suggested (SearchIO, Graphics, some LWP-related DB modules).
> If a fix needed to be made in one set, make the fix, test against
> bioperl 'base' as a whole, and release when possible. No need to
> wait for a full-fledged 1.5.3 release.
What advantage is there of these defined splits instead of individual
modules? As I see it you lose some of the potential benefits of breaking
Bioperl up completely, whilst also suffering the maintenance problems I
outlined in my objection to Steve's post.
Being able to work on all Bioperl from a single cvs (ne svn) check out/
archive, whilst distributing it as individual modules on CPAN seems like
the best of both worlds to me. What am I missing?
More information about the Bioperl-l