[Bioperl-l] Withdraw Bio::Graphics and Bio::DB::SeqFeature from bioperl distribution?
cjfields at illinois.edu
Tue Nov 11 13:05:47 EST 2008
On Nov 11, 2008, at 10:37 AM, Sendu Bala wrote:
> Chris Fields wrote:
>> I'll volunteer to do this. I think this should be a 1.6 release.
>> Users have been screaming for a 'stable' release for years now, and
>> everything on trunk is definitely more stable than 1.4,
> Well, again, I don't see the value in calling it 1.6. Yes people
> want a stable release, but calling it 1.6 doesn't make it stable.
> Doing the things in the plan for 1.6 makes it stable. What you're
> proposing is to just lie to everyone - "You want 'stable'? Here,
> have this thing I decided to label as 'stable'!" It's very wrong-
> headed in my view.
Maybe it's just me, but I don't think having a 1.5 point release
solves the perception issue we have been facing over the years after
the 1.4 release, i.e. bioperl is now in a constant endless 'beta'
release state, even though code on the main trunk is considerably more
stable than past releases. It doesn't help that perception when the
period of time in between simple point releases (1.5.1 to 1.5.2, for
instance) has now extended way beyond what used to be the release
period between major releases.
FOr instance, some sysadmins see 1.5.x as a developer series
(understandably so as it is in our own documentation and FAQ). Ergo
they consider it implicitly 'unstable', so most refuse to install it
(even though we know better). Changing the wiki documentation won't
immediately help that perception; we have all indicated that 1.5 was a
dev release at one time or another, and old documentation floating
around on CPAN or the web doesn't help.
Overall I think we're essentially on the same page. I think the
perception that bioperl is 'dev' is what really needs to be changed,
but I also think the best short-term solution for Lincoln and the
bioperl community is to release something a consensus of users (us,
world at large) consider stable, and according to current
documentation that would be 1.6; we can make regular point releases
for that one on a branch until the next major release. No, it isn't
perfect (we don't accomplish everything we set out to do), but it works.
We can then work on a better long-term solution, which is to change
the perception that the code is 'unstable' or 'beta.' That will come
down the road and will take more time and effort.
> Do we really want all those half-tested, half-thought-out APIs that
> may be hanging around to become official and therefore need to
> support them and make their proper replacements backwards compatible
> come 1.7?
I'm not following you. There are a couple of exceptions but overall
the core API (PrimarySeqI, SeqI, SeqFeatureI, AlignI, etc) has
remained fairly stable for quite a while now, even with some
significant behind-the-scenes changes. Is there something you don't
like about any particular API? Also, there is nothing stopping
developers from trying out a new and possibly better ways of doing
things; you have demonstrated that yourself with PullParserI.
As for backward compatibility, I don't have a problem breaking it if
it needs to be broken (i.e. if it makes sense, such as renaming
methods for consistency). A simple deprecation cycle for old APIs or
methods is par for the course with any software project, and we have
the deprecation tools in place in Bio::Root::* for helping accomplish
> But ultimately it's just semantics so I won't bring it up again. I
> suppose any issues that arise can be solved with a wiki update
> explaining that 'stable' doesn't really mean stable, or that 1.6
> wasn't a stable release, or that our numbering scheme no longer has
> any particular meaning (it doesn't have to, after all).
I agree, but until the word gets out we should forward with what most
sysadmins would consider 'stable', which to me is 1.6.
More information about the Bioperl-l