Mark M. Hoffman wrote: > Hi Hans, Axel: > > And if we're going to put sensors 2.10.x in a deep freeze, then I don't want > to have to make bugfixes in two places, like you say. Thus, I wanted all of > these new features to wait for 3.0. > Now I understand your motivations better!, Thanks. >> branches. Also in this scenario I think we should keep them atleast API >> compatible from the application pov, as some distros may want to ship >> 2.10 then while others ship 3.0. This is exactly why I've suggested to >> turn 2.4 support into an ifdef instead of ripping it out. > > Non-sequitor? I don't understand why distros *couldn't* choose as you say, > or just ship both. OK, so a kernel 2.4 distro can't ship sensors 3.0. But > that's just too bad. They can't ship the most recent udev or modprobe either. > Notice that I said application API this time not application ABI, if we are going to say that 2.10 will stay around in some form for kernel 2.4 + 2.6 users and that 3.0 is all shiny and new for 2.6 only users, then we need them to be API compatible if possible because: -We don't want application programmers to have to put their code full of: #ifdef LM_SENSORS3 ... #else ... #endif -Now assuming 3.0 becomes an instant smash hit then most appplications might just move over, thus requiring 3.0 to compile and run -> problem 2.4 kernel / 2.10 libsensors users are left in the cold / with older versions of these applications Thus as I keep re-iterating breaking (not extending but breaking) the API for the single goal of moving from pass by value to pass by const reference one way or the other causes users pain and IMHO more pain then gain. Regards, Hans
