[Bioperl-l] Bio::Species, Bio::Taxonomy::Node overhaul

[Chris Fields]

On Aug 12, 2006, at 9:33 AM, Sendu Bala wrote:

> Hilmar Lapp wrote:
>>
>> On Aug 12, 2006, at 10:07 AM, Sendu Bala wrote:
>>
>>> No, will do. Where would I put the changes? Add them into the 1.5.1
>>> section, or does the 1.5.1 section contain only the changes that  
>>> were
>>> present at the time of its first release? Should I make a 1.5.5  
>>> section
>>> instead? And should I move the Main trunk points to the new 1.5.5
>>> section as well?
>>
>> I'm still confused as to why we are jumping from 1.5.1 to 1.5.5.  
>> Also,
>> I'm confused as to why some of the pre-1.5.1 changes are under Main
>> Trunk, and not under 1.5.1. So I guess I'm the wrong person to  
>> answer ...
>
> Well, Chris seemed to like 1.5.5, but 1.5.2 makes more sense to me.
> Shall we make it 1.5.2 Chris?'

I believe '1.5.5' originally came from Brian as suggestion for an  
intermediate developer release prior to 1.6, that's why I brought it  
up (I thought it was already decided upon).  This came up sometime in  
the spring when Jason was prepping for his defense and we were  
thinking about future Bioperl releases.

We could easily change that to 1.5.2, 1.5.3 etc. (stick with point  
releases), and have a few more point releases prior to 1.6.  I have  
no problem with that; makes more sense to me.

These are developer point releases anyway.  Release 1.5 had bugs; v  
1.5.1 fixed those.  1.5.2 and beyond can address bugs that pop up but  
also introduce new modules, new functionality (UCSC), etc, all the  
time working on the project priority list, tests, POD, etc.  Once we  
reach a particular point, we need to work towards making the next  
stable release; i.e. stabilizing the API, completing other unfinished  
business, and focus less on introducing new stuff.  At least that's  
the way I have understood the process from other projects.  Sound  
about right Hilmar?

 From the FAQ:

"Developer releases are odd numbered releases (1.3, 1.5, etc) not  
intended to be completely stable (although all tests should pass).  
Stable releases are even numbered (1.0, 1.2, 1.6) and intended to  
provide a stable API so that modules will continue to respect the API  
throught a stable release series. We cannot guarantee that APIs are  
stable between releases (i.e. 1.6 may not be completely compatible  
with scripts written for 1.4), but we endeavor to keep the API stable  
so that upgrading is easy."

Hilmar is also right in suggesting there is a problem with making  
commits to Main w/o also including the tagged branches.  I am as  
guilty of this as everyone else, but I think much of this stems from  
the lack of a new 1.5.* branch to commit to.  This was a problem that  
Fernan Aguero pointed out which has effectively 'hobbled' much code  
in Bioperl 1.4, but we're now beyond the point of updating that now;  
v 1.4 was released Dec. 2003 and way too much has been added since then.

Fernan's suggestion was to have someone (not the Release pumpkin)  
maintain regular point releases for stable versions and suggested  
himself for the job.  These would be primarily to fix bugs (no API  
changes allowed).  I think it's a great idea; it frees up the  
developers to think about the future by plotting a course for the  
next developer release and the following stable release.

Chris

Christopher Fields
Postdoctoral Researcher
Lab of Dr. Robert Switzer
Dept of Biochemistry
University of Illinois Urbana-Champaign