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
