On Fri, 25 Apr 2014 19:25:49 +0900 Jean-Philippe André <j...@videolan.org> wrote:
> 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. While I'm kinda annoyed that this big blob of 3D code seemed to arrive completely out of nowhere, especially since I've made lots of noises in the past about working on 3D virtual worlds (so someone should have warned me dammit), I'll be playing with it. As soon as the E b0rk mailing list says it stops breaking the build. And possible after I'm done juggling stuff around my hard drives. My big virtual world project is not likely to get to any "usable by others" stage any time soon, so I'm happy to try out new or experimental stuff with it. Hell, it's not even usable by me yet. lol So my vote on whether or not to hide stuff behind a big THIS_IS_BETA switch doesn't really matter. If the switch exists, I'll be turning it on. I'd be inclined to vote for the big switch though. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
