[prev in list] [next in list] [prev in thread] [next in thread] 

List:       enlightenment-devel
Subject:    Re: [E-devel] EFL Beta API
From:       Gustavo Sverzut Barbieri <barbieri () profusion ! mobi>
Date:       2013-07-30 15:24:43
Message-ID: CAPdpN3B4FikTx+ivzuKMOD-p6-bgXeRomjU4kZdLr-w73-ux0Q () mail ! gmail ! com
[Download RAW message or body]

the infamous #ifndef
EO_IS_UNDER_DEVELOPMENT_AND_API_WILL_CHANGE_AND_I_KNOW_ABOUT_THAT;
#error "Eo is under development and API will change"; #endif should
help. I don't mind the actual libname/release it we make sure the code
is aware of that.

On Tue, Jul 30, 2013 at 5:28 AM, Cedric BAIL <cedric.bail@free.fr> wrote:
> On Tue, Jul 30, 2013 at 8:56 AM, Lucas De Marchi
> <lucas.demarchi@profusion.mobi> wrote:
>> On Tue, Jul 23, 2013 at 5:29 AM, Cedric BAIL <cedric.bail@free.fr> wrote:
>>> On Tue, Jul 23, 2013 at 5:04 PM, Michael Blumenkrantz
>>> <michael.blumenkrantz@gmail.com> wrote:
>>>> sure, but it sounds more like "pre-alpha" than beta at this point
>>>> considering the amount of rewrite occurring.
>>>
>>> There is still no agreement about if we are going to change any of the
>>> existing API or not. It is still a discussion. And the change is going
>>> to impact mostly EFL internal than an application using EFL.
>>
>> Humn... even then I'd say it would be better to do one of the below:
>>
>> 1) Keep it private and link statically to Eo.  This has the downside
>> that now every lib has to link statically and grows  (side note.. is
>> there any plans for libelf.so?)
>
> A libefl.so maybe at some point in the future. Not 1.8, nor 1.9 at least.
>
>> 2) Remove the versioning from libeo.so so we can do a proper release
>> later without bumping the major (which would look odd compared to the
>> other libs)
>
> I do see the point of both 1 and 2, but if all application using it
> are always one from upstream and released together, then is that a
> real problem ? I don't like the idea of removing the versioning to
> much, but it sounds like a viable solution. Reason that I don't like
> it, is that it only solve the case for Eo.
>
> In the future, I hope to switch to a time based release for EFL, that
> would require to be able to mark some API as BETA and not supported.
> So application that want to use it need to be released in sync with
> EFL. I don't see any solution around that problem. We can say that we
> will all work in a branch and people will test... but we all know that
> very few people do test or review other branch. We just don't have the
> man power to do that.
> --
> Cedric BAIL
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[prev in list] [next in list] [prev in thread] [next in thread]