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

[Chris Fields]

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  
that.

> 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.

chris