Re: gr version hell gets bigger and bigger...

[Martin Braun]

On 1/29/20 3:44 AM, Ralph A. Schmid, dk5ras wrote:
> Hi out there,
> 
> only a common remark :) I am using gnuradio for around six or seven years
> now, and such issues were always present, but I never experienced them in
> the extent like nowadays. 
> 
> More and more I am trapped in version conflicts. [...]

All,

I would like to wrap up this thread. Nothing anyone said here is
inaccurate or untrue: Ralph has a good point, that it is difficult to
maintain OOT modules against different versions of GNU Radio is
definitely true. And that's not just as a 3rd-party user, that's even as
the OOT maintainer. So, what can we do about that, and why is it like that?

Marcus already gave some of the rationale. There are things that simply
need to change. When we went from 3.6 to 3.7 we did an important step to
improve modularization of our codebase. From 3.7 to 3.8 we had years of
backlog, and our dependencies were EOL. In the case of Python, that also
meant removing Cheetah, which was this incredibly deep rabbit hole we
had to go through. Going to 3.9, we are currently planning on ditching
SWIG, which will be another change, and might screw up OOT modules again.

However, we carefully balance all of these decisions against their
costs. In some cases, we have no choice (like deprecating Python), in
other cases, we apply judgement from our years of experience to see how
OOT modules would be affected. Because not only are OOT module authors
affected, so are we as the maintainers of the main source tree.
When there are bigger changes, we discuss these in public, too. Hence
the GREPs: https://github.com/gnuradio/greps/

Changes to the core code that then affect external plugins are a common
problem. Projects like Jenkins, Wordpress, even stuff from PyPI will
only work with a range of versions of the base code.
GNU Radio may or may not be different from these examples, due to its
CMake-project-per-OOT structure, but ultimately there's only so much we
can do for various people's OOT modules.

Maybe there are things we *can* do:
- Improve migration guides
- Possible create automatic migration tools
- Improve PyBOMBS to help managing the version chaos
- ...?

All of the above will require people helping us to do those, though.
We're open for suggestions. We cannot make guarantees about other
people's OOT modules, though.

Cheers,
Martin