On Sat, 19 Nov 2011 14:24:46 -0200 Lucas De Marchi <lucas.demar...@profusion.mobi> said:
> On Sat, Nov 19, 2011 at 7:25 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > while making connman work and improve is good... the edbus connman api has > > been quite heavily broken now. > > > > this is now a blocker for efl 1.1 and we can't release until resolved. > > here is what has happened: > > > > e_connman_service_apn_get() removed > > e_connman_service_apn_set() removed > > e_connman_service_ethernet_netmask_get() removed > > e_connman_service_mnc_get() removed > > e_connman_service_mode_get() removed > > e_connman_service_security_get() api/abi break in parameters passed > > e_connman_service_setup_required_get() removed > > > > we can't release with all these breaks. we are the ones providing an > > advertised stable api to talk to connman. if connman itself breaks api, it > > is our job to do either: > > I think there's not point in saying we implement a stable connman API. > There's no way to check at runtime what is the version of ConnMan and > doing all the work to be compatible with previous api is totally > insane. then bump the major .so version and bump up the pc to be econnman-2.pc and move the headers to e_dbus-2/ instead of e_dbus-1/, make sure all the autofoo does the right thing there in the build tree and make sure everyone knows it. the problem is they kind of don't because its hidden inside a debus-1.x tarball bundle. it's a pretty simple rule. you DON'T BREAK API OR ABI of a library within the same major version. > E.g. the case a property changed from plain string to an array of > strings. The natural name of the method for *future* versions cannot > be used. after all the "we must release! release!" now this is not wanting to accept the responsibility of a release, and that is to keep compatibility. it is the responsibility of the library writers to keep that compatibility - regardless what the connman dbus protocol does. the protocol provided a single string before, and now its an array - well my bet is in that array somewhere IS that original string - so for compatibility you make the old api provide the "first string in the array" for example. yes - it's a pain. yes. it's work. yes connman dbus protocol changed - but that's not a pain you pass on to your api users WITHOUT a big red blinking sign saying "look - it broke! don't upgrade to this unless you are prepared to do some porting work on your code". if e_dbus was 0.x.x - we could pass it off as "hell it's still getting its act together so it has no clue what api to use". > As such the plan is to support the most recent versions packaged by > distros, at least until the ConnMan API becomes more stable. This is > why we added this in E_Connman.h: added... but it wasn't there on 1.0. 1.0 set up the playfield with an advertisement of stability as long as its 1.x - every time api breaks you also drive people away - ESPECIALLY when the api breaks after a 1.x AND even more when you break it withotut changing major version. i'm just saying - that by writing a library with a public and stable api it is the responsibility of that author to not break api or abi during the lifetime of that major version. doing so simple breaks the rules and conventions laid down in unix and linux over decades that let people know that there was a break. :) > #ifndef E_CONNMAN_I_KNOW_THIS_API_IS_SUBJECT_TO_CHANGE > #error "E_Connman.h is an unstable API linked to upstream connman project" > #endif > > > However I really hope that at the time this happens we don't need this > submodule anymore. Gustavo began to work on a tool to generate the C > bindings (just like there's in, for example, qt and glib) to ease the > use of dbus. Therefore we would not need this part of the lib and the > application could directly use dbus. then maybe copy the existing connman code into e17's connman module and replace that code when codegen works. we can keep shipping the e_dbus connman forever and not change its api or abi. :) > For *this* release, it's sufficient to say we don't provide an stable API. unfortunately.. it's too late for that. it's a stable api because it was in january when released as 1.0. this is the price u pay for making a stable release that every distro and packager and user is demanding of us. > Lucas De Marchi > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
