Hi Andreas,
(Sorry, our mails seem to have crossed in the ether!)
On 15:12 22/07, Andreas Tille wrote:
> Hi Sascha,
>
> On Fri, Jul 22, 2016 at 01:40:40PM +0100, Sascha Steinbiss wrote:
> > >
> > > - refers to v1.4, AFAIK version 2.0 is already in the archive, so this
> > > one should probably me closed.
> >
> > I don't think it is [1]. Anyway, AFAICS SeqAn 2.0 is intended to go into
> > a separate package seqan2 instead? Some of the recent mails here on this
> > list seem to indicate that?
> > The seqan repo in Git has 2.0 already merged into master but not
> > uploaded yet. Can anybody clarify please?
>
> My *personal* and *totally* uneducated opinion about seqan is that we
> should *not* try to maintain two versions of seqan - specifically not an
> old an currently RC buggy version. Thus it would be better to keep the
> name seqan also for version 2.x.
>
And for my similarly personal and uneducated opinion: I'd love this to be true,
but it could be a little optimistic. See below.
> > If there is going to be a new repo for seqan2 because of API changes I
> > think it might be worth fixing the GCC6 FTBFS in the 'old' (1.4) seqan
> > package to make sure that important tools depending on 1.4 (such as
> > bowtie, tophat, ...) stay in testing.
> > What do you think?
>
> Seqan API has changed in minor 1.x versions as well and we managed to
> patch the said tools. I'm simply hoping we can follow this strategy
> also for seqan 2.x. Thus my suggestion to upload seqan 2.x as fast as
> possible to experimental and see what we can do for the dependencies.
>
> Please note: I'm not deeply involved in all the internals and my
> opinion might be at best naive, maybe totally wrong. However, it seems
> that we do not have the power to maintain seqan 1.4 over a long time
> (several releases).
>
>From my somewhat limited experience, the 1.x -> 2.x changes are quite
fundamental. Like introducing entirely ways of doing certain things, e.g. any
sequence file IO. I think that you're correct for trivial uses or changes that
are easily handled with sed (and we should patch away to our hearts' content).
But I am almost certain that there will be packages where much manual work is
required as API changes are non trivial.
There are also these facts to consider:
a), seqan 1.x is on it's final minor release, and shouldn't be needing much
updating at least from upstream.
and b), upstream tool developers will *eventually* have to move to 2.x of
their own accord and having the folks who wrote the tools do the API
transition is better for all concerned.
All in all, I think that having seqan 1.x in Stretch makes sense. Certainly, we
should deprecate it, and be proactive encouraging upstreams to migrate to 2.x,
but the burden of fixing a few GCC 6 FTBFS sounds a lot less to me than
patching a bunch of tools that are stuck with the 1.x API.
All $0.02's welcome, I'm hardly an expert in any of this. (Particularly ping
@mr-c)
Cheers,
K
---
Kevin Murray
0xA4B4EE6A
