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

Re: Seqan2 (Was: Thanks to Gert and Sascha - other please keep on fixing bugs)



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


Reply to: