NetworkManagerQt (aka libnm-qt) is a work in progress library and I am working on to make it ready for its first release. There are some useful features in NetworkManager 0.9.8.x that does not exist in 0.9.6.x:
- wifi ap-mode for more stable and secure wifi connection sharing. This is the main reason for using NetworkManager 0.9.8;
- bridge support;
- more connection states to correctly handle notifications about... guess what? Connection states.
Even Plasma NM 0.9.0.9 now depends on NetworkManager 0.9.8.x because of bug 320533. Ok that 320533 is a small bug, if you do not want or cannot upgrade NetworkManager to 0.9.8.x you can still use Plasma NM 0.9.0.8, there is little difference between Plasma NM 0.9.0.8 and 0.9.0.9. However, I think it is reasonable that NetworkManagerQt depends on the latest stable NetworkManager version. After all NetworkManagerQt is not a stable library yet, we do not even keep binary compatibility for now. Sure we are going to keep binary compatibility from first NetworkManagerQt release on though.
I plan to keep NetworkManager 0.9.8.0 as dependency for NetworkManagerQt 0.9.8.0 (first release), so this problem should be mitigated as distributions continue to pack NetworkManager 0.9.8.x. Minimum NetworkManager required is going to be bumped only when really necessary, which was the case for the wifi ap-mode.
7 comments:
I post my comment here instead of on the original dfaure post because I do not want to register on yet another site (I am suffering from "registration overdose", even the simple act of registering and adding the password to KWallet is too much).
For a new contributor it is a lot of work to compile and install all dependencies, so the post of dfaure is understandable. But IMHO it is a good thing that the developers develop their software using the latest version of the dependencies, because when their software is finall y released, it will live together with the currently latest version of the dependencies. I experienced on several occasions that software (including my own software) developed with what the distro currently ships does not work correctly when the software is finally released and its dependencies are available in a more recent version. The real problem, therefore, is not that the dependencies are too recent, but that the distros ship way too old versions of the dependencies. As you noted, even versions which have already been released half a year ago are not available in the current stable releases of some bigger distros (Opensuse, Kubuntu, ...).
I think the main point was that it would be good to have the code compile also against a bit older dependencies also. The new features could be #ifdef:ed untill most distributions ship the new dependency. :)
#ifdef's are evil, I cannot sacrifice code readability by putting #ifdef's in a library that has never been released before. This is not about stable code, NetworkManagerQt is still in development for the *first* release. After the first release I will use #ifdef if necessary, until then I am going to break binary compatibility, change API and do whatever it is necessary to make the first release as stable as possible.
Actually, current NetworkManagerQt state is kind of "for experience hackers only". The library alaredy works but needs some polishing, newcomers do not understand what polishing changes are necessary now, only experienced developers would understand things like what it takes to keep binary compatibility, source code style, good API, code optimization, write good documentation for the API, create good examples on how to use the library, etc.
> four months that NetworkManager 0.9.8.0 was released, it should be packed by distributions already.
That part made me laugh, thanks, backward compatibility? Ah!
@Anonymous, NetworkManager 0.9.8 is backward compatible with older NetworkManager 0.9.x versions. NetworkManagerQt is an unreleased library, there is no need for backward compatibility here because there is no older NetworkManagerQt version to be backward compatible with. So why are you laughing?
is "wifi direct" feature implemented in nm and plasma-nm ?
this becomes a big trend
and it tends to replace bluetooth
i see also that digikam supply DLNA connection
@Promeneur, actually we have never thought implementing direct wifi. I also have never used it, I need to know if it works with NetworkManager itself. If does, than we can implement the support for it in Plasma NM.
Post a Comment