The Perl Advent Calendar needs more articles for 2022. Submit your idea today!

Working with development sources

BioPerl uses Dist::Zilla to author releases. You will also need the Dist::Zilla::PluginBundle::BioPerl installed as well as its dependencies. Then, you can run the following commands:

dzil test
dzil install

The Directory Structure

The bioperl-live repository structure is organized as follows:

Bio:: namespace summary

The BioPerl project is split over multiple Perl module distributions. The BioPerl distribution is the BioPerl core distribution, including a selection of modules and namespaces but not all. For example, the entire Bio::Biblio is not included in the BioPerl distribution. Similarly, while many Bio::SearchIO modules in the BioPerl distribution, there also Bio::SearchIO modules in other distributions such as Bio-SearchIO-blastxml.

This section describes most of the Bio:: namespaces developed by the BioPerl project, including those which are not part of the BioPerl distribution. For example, the Bio::Biblio and Bio::Assembly are documented here but are not part of the BioPerl distribution.

Releases

BioPerl currently uses a semantic versioning scheme for version numbers. Basically, a version has three numbers in the form MAJOR.MINOR.PATH, each of which changes when:

  1. MAJOR --- incompatible API changes,
  2. MINOR --- new functionality in a backwards-compatible manner,
  3. PATCH --- backwards-compatible bug fixes.

1.7 releases

Before 1.7 release, the BioPerl project had a single distribution with all of BioPerl modules. During the 1.7 release series, subsets of the modules were extracted into separate distribution.

Pre 1.7 releases

From version 1.0 until 1.6, even numbers (e.g. version 1.4) indicated stable releases. Stable releases were well tested and recommended for most uses. Odd numbers (e.g. version 1.3) were development releases which one would only use if interested in the latest features. The final number (e.g. in 1.2.1) is the point or patch release. The higher the number the more bug fixes has been incorporated. In theory you can upgrade from one point or patch release to the next with no changes to your own code (for production cases, obviously check things out carefully before you switch over).