On Thu, Apr 28, 2016 at 3:31 PM, Lamar Owen <[email protected]> wrote: > [Reply comments in-line.] > > On 04/28/2016 01:41 PM, Marcus Müller wrote: > >> It's not about not updating – it's about not breaking possible existing >> usage! RH has to make sure that software stays binary-compatible, so >> they can't use a different version if it has a different ABI. >> > > I not only am aware of the policy, I agree with the policy, and am > attempting to work within the framework established by the policy. > > GR changes ABI between revisions, and if you change ABI, you're expected >> to offer a "-compat" package, even for EPEL. >> > > Hmm, the ABI changed between 3.7.5 and 3.7.9? Is there a document > somewhere that documents the criteria for what consitutes major versus > minor versus releases? In my humble opinion, and going from historical > experience with a package that I maintained for five years, an ABI change > should be a major version thing, or a minor version thing but not a > revision thing (I read the version number of current stable GNUradio as > major version 3, minor 7, revision 9, release 2; am I reading that > wrong?). I base my impression on PostgreSQL; 7.0 to 7.1 was an ABI (and > database format) breaking change; 7.0.0 to 7.0.1 was not (and I maintained > RPMs of those specific versions, up until the beta period for 8.0). Am I > wrong when thinking this with GNUradio? > > Yes, if there is an ABI (or an API) change then that's a different ball of > wax. >
You can see the criteria we have for our version numbering here: http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeSets And we have never promised or provided ABI compatibility. We embed the version into the name of the libraries, though, for people to explicitly link to the version they need, such as libgnuradio-runtime-3.7.9.2.so. ... >> Central question here is why *you* can't live with 3.7.5; actual user >> necessity be the main thing that someone might consider a reason that >> "can't be avoided". >> > > And that's the crux of my question: concisely, are there any 'you really > need to update and can't avoid it' changes between 3.7.5 and 3.7.9? If > not, then there's no reason I can't use 3.7.5, really. That's part of the > reason I'm working with CentOS 7 AArch64 on the ODroids to begin with, as I > want to be consistent. And if 3.7.5 is fine, then I can do that on all my > C7 boxen; if there is a compelling reason to go to 3.7.9.2 then I will want > to be consistent there, too. I would think "probably not" within the 3.7 API version series. There have been plenty of additional features and bug fixes, but whether or not they are critical depends on your needs and applications. But I'd say the burden of proving "can't avoid" is pretty high. You can look through that link I pasted above where we catalog the changes in all of our releases to see if anything sticks out at you, though. Tom Really, CentOS 7 is pretty stable distro. If you need a version that >> they don't offer, your best option probably really is to do the rpmbuild >> dance, building your binaries from a modified SPEC file that uses the >> GNU Radio source code version of your choice. >> > And I know how to do that if I need to do that. > > Thanks for the good answers, Marcus.
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
