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
