2014-04-25 19:11 GMT+09:00 Cedric BAIL <cedric.b...@free.fr>: > Hello, > > On Fri, Apr 25, 2014 at 11:07 AM, Jean-Philippe André <j...@videolan.org> > wrote: > > 2014-04-25 17:49 GMT+09:00 Stefan Schmidt <ste...@datenfreihafen.org>: > >> Triggered from the Evas 3D commits I talked with jpeg about having a > >> flag that controls if unstable API's are enabled or not. > >> > >> This would allow us to have big new features, I have Evas 3D in mind > >> here, in the coe base but have it hidden behind an BETA API flag so we > >> are not bound to stick with the API until we are happy with it. > >> > >> It should not be used to get all kind of crap into the code base > >> though. I see it as a mechanism to give the code time to mature for > >> one more release cycle. If we are happy with the API we will remove > >> the BETA guards around it. On the other hand if we still are not happy > >> with it after 3 months in the new cycle we can as well remove it from > >> the master branch and give it more love before it will go in again. > >> > >> Jpeg was thinking about it for new functionaliyt of an existing API. I > >> guess we could handle this as well. > > > > I was thinking of my "filters" API which was hidden behing EO and BETA > > flags for EFL 1.9. > > But since we now actually use Eo with Eolian, the API itself is > > auto-generated. > > > > So, we'd need Eolian to not generate some bindings for the legacy API. > > Add a @beta flag or something in the EO file. > > > > Then, only the EO binding is generated, and the legacy API is not. > > But I'm not sure if we can hide the symbols in the final library, since > EO > > now uses real functions as entry points? > > Right now I do prefer that we do compile the code and require > application that want to use it to explicitly require the flag. I see > two reasons for it, first it prevent code rotting (obviously being > compiled by everyone is better). Second it doesn't require a special > package to try the beta API. Also for this release all Eo API is still > in alpha with high risk of seeing its ABI and API broken for next > release. It would means no binding at all for this release. So nobody > will start playing with it. > > Also what would be the value of not compiling the code ? It will > increase our code complexity and the chance to accidentally break > something. > > Maybe I wasn't clear enough... I never mentionned not compiling the code. Only disabling the API. Apps that want to use it must #define EFL_BETA_API or something like that to use it. And then they know it's unstable.
Which basically means (now) it should only be part of EO APIs and not in legacy headers. I agree with you that the code should always be compiled, quietly tested, and if possible also used by core developers. Cheers, -- Jean-Philippe André ------------------------------------------------------------------------------ Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
