[Bioperl-l] Withdraw Bio::Graphics and Bio::DB::SeqFeature from bioperl distribution?

[Chris Fields]

On Nov 11, 2008, at 3:02 PM, Mark Johnson wrote:

> On Tue, Nov 11, 2008 at 1:52 PM, Hilmar Lapp <hlapp at gmx.net> wrote:
>> I think the main danger with a haphazard 1.6 stable release is to  
>> have APIs
>> in there that we aren't ready yet to commit to supporting beyond  
>> 1.6, or
>> even beyond 1.6.0.
>
>    I think not having a 1.6 release at all is a bigger danger than
> possibly shipping some half-baked APIs.  I'd rather ship now,
> deprecate later.  But I'd say it's all up to Chris.  He's the one with
> the time and energy, so I think we get what he's willing to do.  8)

Energy maybe, but time, eh, not so much anymore (job is taking up much  
more time now).  We could definitely use more hands, but hopefully  
setting a plan will pull more folks aboard.

>> If there are hidden (or known) bugs, these can be declared, and  
>> fixed in
>> point releases. (I do feel pretty strongly that a much greater  
>> frequency of
>> point releases is necessary and healthy. There was talk earlier  
>> this year
>> that a 1.5.3 release is not worth the effort and that we should aim  
>> for 1.6
>> right away. I think such consideration is nearly always mistaken, and
>> backfires - in this case the result of it was that we have had  
>> neither 1.5.3
>> nor 1.6 for 8 months: those feeling capable of shepherding 1.5.3  
>> were told
>> their time isn't needed, and those wanting to take on 1.6 were  
>> intimidated
>> by the necessary effort. Had there been 3 point releases since  
>> then, we may
>> have gotten to 1.6 in smaller steps at a time but eventually faster.)
>
>    I think perhaps the previous goals for 1.6 exceed the available
> developer manpower.  It's fine to say "we'll ship 1.6 when X, Y and Z
> are done", but I think the situation we find ourselves in now is such
> that we can ship the trunk or not ship anything.  The latter course of
> action could quite possibly see the splintering or dissolution of the
> project.

I'm not sure it would be that extreme, but that's possible, yes.

>> As for sanctioning APIs that aren't ready to receive official  
>> blessing by
>> releasing 1.6, what about individual developers taking  
>> responsibility and
>> clearly label their module and interface declarations as  
>> experimental if
>> that's what they are. I don't think it's unreasonable either to  
>> just declare
>> all new (since 1.4) APIs that haven't been vetted or approved by  
>> the core as
>> experimental. They can always be de-experimentalised later.
>
>    Works for me.
>
>> And finally - awesome Chris that you are volunteering to carry the  
>> 1.6
>> torch! Much thanks, and may the Force be with you :-)
>
>    I think we all owe him mass quantities of his preferred beverage
> at the earliest opportunity.

Let's see how things turn out before handing out free beverages.

chris