[Bioperl-l] How to handle bugs in bioperl 1.4 on CPAN?

[Fernan Aguero]

+----[ Hilmar Lapp <hlapp at gmx.net> (26.Jun.2006 07:22):
|
| We did not and will not deposit 1.5.1 into CPAN due to the API issues  
| in some (rather central) interfaces. These issues are changes over  
| the 1.4 API and some of those changes are going to go away. Once we  
| deposit it into CPAN we would sanction the changed API as the new  
| 'official' API and would open a huge can of backward liability worms.  
| If you just continue to use the 1.4 API on the 1.5.1 release you  
| don't need to be concerned about an API method you're using going away.
| 
| As I said, the people from the core group of developers who have  
| traditionally shepherded releases all think that doing a 1.4.1  
| release wouldn't be the best investment of their time. You are most  
| welcome to disagree and volunteer your time to coordinate the 1.4.1  
| release, and a lot of people will appreciate your efforts - including  
| the bioperl developers and 'core'. It shouldn't be much work  
| theoretically.
| 
| 	-hilmar
|
+----]

I understand that, being a volunteer project, people can
decide where to best invest their time. If core developers
are no longer using 1.4 in their production setups, it is
reasonable to expect that they invest all of their time in
1.5 or any other bioperl version that they're using.

However, when view as an issue related to the setting of a
policy for the whole project, then it makes sense to have a
policy saying for how long a stable release will be
supported, and when and in which case bugfixes that are committed
to and tested in the development branch (as it should be)
will get merged back to stable. 

I'm not knowledgeable enough about the bioperl release
engineering process, nor about the internal development
process, but just guessing I'd expect that whenever anyone
submits a bugfix, it should be the responsibility of
the committer to check (against the project policy,
(written or implicit) or with the core developers in a
difficult case) whether the fix should be committed to more
than one branch.

A patch like the one that started this thread, should have
been committed to the 1.4 branch without too much thinking.
And it would have cost the committer only a few seconds more
of her/his time. 

But you only get this by setting and enforcing a policy.

After a number of these fixes has accumulated, then making a
new release shouldn't represent too much effort, nor it
should be expected that the tests that passed before would
break now. And in the worst case (no tarball release),
people can be directed to obtain the most current 'stable'
code from the repository, containing all bugfixes. 

I guess that this is what was meant by Phillip.

Fernan