[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Another issue in test suite of new version of bioperl.

On Wed, Feb 06, 2019 at 01:35:23PM +0000, Carnë Draug wrote:
> > On Tue, Feb 05, 2019 at 04:53:44PM +0000, Carnė Draug wrote:
> > >
> > > There was a bug on the test for requires_networking.  It should be
> > > fixed on the 1.7.4 version that was released today.
> >
> > Thanks for the pointer - uploaded yesterday.  Any solution for the
> > issue with bioperl-run (#921495)?
> >
> I replied on the bug tracker for that specific issue.
> But please read the Change file of the release.  There has been a
> *lot* of changes on the last release.  There's almost no bug fix, it's
> all about removing modules, removing programs, adding new modules from
> other distributions, and dropping dependencies.
> One very nice change is that this release breaks the circular
> dependence on bioperl-run (bioperl was dependent on bioperl-run which
> the was dependent on bioperl)
> Many of the modules removed were moved into separate distributions.
> But while there's a repository for those new distributions, upstream
> has not actually made releases.
> Also, note that in CPAN, this is the BioPerl distribution.  In Debian
> there's the bioperl source package, the debian bioperl binary package
> (scripts from that package), and libbio-perl-perl (the perl modules).
> However:
>     1) the BioPerl distribution no longer has the Bio::Perl module so
>     the name libbio-perl-perl would no longer be a good match.
>     2) upstream does not consider bioperl to be the scripts.  The
>     scripts are just a secondary thing.  BioPerl main thing are the
>     modules.  And with the split of bioperl into smaller modules,
>     there is also bioperl the project which would be all of the
>     bioperl distributions.

Hmmm, I admit I have not expected this kind of heavy changes in a micro
version change release.  I'm tempted to either file an RC bug to block
migration of this release or even use an epoch to revert that upgrade.
That's a lot of changes right before the freeze and I do not want this
to go into Buster.  What solution do you prefer?

BTW, you could help distributors realise these kind of changes by
choosing a more usual versioning sheme - for instance 1.8.0 or 2.0.0
would have forced me to read the changes and have prevented me from

Kind regards



Reply to: