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

[Mauricio Herrera Cuadra]

I also vote on making it a 1.6 release, stable or not.

Maybe it is the time to get rid of the even/odd versioning scheme at 
all? The scheme might have worked well in the past but now it's becoming 
more of a roadblock/legacy thing which is stopping the project to move 
forward and evolve.

Just take a look to what other Bio* projects are doing. BioPython for 
instance, is releasing a new version every couple of months with the 
best of both worlds: fixes to bugs in the previous versions as well as 
new beta/experimental features which let them be more in sync to 
whatever external dependencies they require (i.e. they always try to 
support the latest version of Python, NumPy, etc.), and they're evolving 
fast!

This could be an opportunity to switch to a more dynamic release cycle 
in which "stable" refers to the latest tagged/packaged/released code put 
into CPAN and "bleeding edge" refers to the latest code in the 
repository trunk. No more headaches about differences between major 
releases, and no more "you should try using 1.5.2 or bioperl-live 
instead of 1.4, which is our 'stable' release but quite old and 
unsupported" speech.

It seems to me like making a HUGE plan for every release is eventually 
stopping it from happening at all; the bar has been raised far to high. 
I believe that we need fewer, short-term fixes/changes/enhancements as 
goals for making minor releases (1.6.0, 1.6.1, etc.), that should be the 
way to go from now on. We could be making minor releases a lot more 
often, so the split of the APIs into the proposed sub-packages can be 
gradually achieved and, once that happens, we could start thinking of a 
new 1.7 release series.

Why don't we categorize the items listed in 
http://www.bioperl.org/wiki/Release_Schedule#Bioperl_1.6 and 
http://www.bioperl.org/wiki/Project_priority_list and group them into 
minor releases along with setting a regular release schedule? We all 
know it is impossible for everything to be working at a 100% always, and 
even if only a few patches have been made to the code base between 
release dates, we should simply make another minor release so things 
keep moving.

Just like others here, I'm happy to help in whatever I can to make this 
happen.

Cheers,
Mauricio.


Chris Fields wrote:
> 
> 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
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>