[Bioperl-l] Withdraw Bio::Graphics and Bio::DB::SeqFeature from bioperl distribution?
Mauricio Herrera Cuadra
mauricio at open-bio.org
Tue Nov 11 18:02:39 EST 2008
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
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
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/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
Just like others here, I'm happy to help in whatever I can to make this
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
>>> 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
>>> their time isn't needed, and those wanting to take on 1.6 were
>>> 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
> 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
>>> 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
>>> 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.
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
More information about the Bioperl-l