multiple versions Re: python-cyvcf2 test failures (Was: python-pybedtools: fixing the failing tests)
On 7/22/18 5:15 PM, Andreas Tille wrote:
> Hi,
>
> On Sun, Jul 22, 2018 at 04:16:36PM +0200, Steffen Möller wrote:
>> b) assess downstream effects of bedtools' changes to merge and sample
>>
>> The answer to a) could be what I started with
>> https://github.com/daler/pybedtools/pull/250 - let's see where this goes.
> +1
>
>> For b) I think we should provide two versions of bedtools - v2.26 and
>> 2.27.1.
>>
>> Opinions anyone?
> I disagree with providing two versions for very low popcon packages. We
> will end up in a maintenance hell if we try to put our really low
> manpower on two *minor* versions of some software just because upstream
> decides to break compatibility and some downstreams do not follow. I'd
> prefer if we could fix downstream (python-bedtools) to support the
> latest interface since this is sustainable in the longer term.
We need to think of something, though. Somehow the notion of a stable
API seems to be losing grounds. And folks like conda don't even notice
this much - they just go and change a >= to = in their dependencies.
Our standpoint was that we as a community help identify such breakages
and help fixing them. But for bedtools we have semantic differences in
its tables that are unfixable. And this will get worse as an increasing
number of communities are adoping conda build scripts.
We also had this with Java a lot and strictly versioned maven
dependencies. This seems to have improved over time, but from what I
perceive, it is still not perfect.
There are other pressing things on my end for the remainder of this
month. But I think I am still for introducing a second package. Please
discuss this at DebConf. Maybe someone finds a way to include
snapshot.debian.org in build processes, which basically breaks the
concept of releases but lets us specify environments dynamically - just
like conda is doing it.
Cheers,
Steffen
Reply to: