> -------- Original Message -------- > Subject: Re: [E-devel] What are we going to release? > Local Time: December 6, 2017 5:22 PM > UTC Time: December 7, 2017 1:22 AM > From: ras...@rasterman.com > To: Enlightenment developer list <enlightenment-devel@lists.sourceforge.net> > Cedric Bail <ced...@ddlm.me> > > On Wed, 06 Dec 2017 19:45:39 -0500 Cedric Bail ced...@ddlm.me said: > >> Hi, >> >>> -------- Original Message -------- >>> Subject: Re: [E-devel] What are we going to release? >>> Local Time: December 6, 2017 6:13 AM >>> UTC Time: December 6, 2017 2:13 PM >>> From: dan...@octaforge.org >>> To: enlightenment-devel@lists.sourceforge.net >>> On Wed, Dec 6, 2017, at 14:26, Andrew Williams wrote: >>> >>>> Hi all, >>>> As our last release was over 4 months ago I think we really need to >>>> figure >>>> what the next release will be, and when, so we can start focusing on >>>> making >>>> that subsection of our work releasable. >>>> Clearly we are not going to get the interfaces completed any time soon. >>>> The >>>> list of things to port keeps getting longer and we have too many >>>> outstanding patches to count. I have heard suggestions that we could >>>> release a subset, for example Efl_Core and Efl_Net now that they we have >>>> the Efl namespace split into groups. >>>> This would mean releasing the API ( >>>> https://www.enlightenment.org/develop/api/start) that is prefixed efl_io, >>>> efl_net, efl_event or efl_loop and that's about it (as well as eina and >>>> eo >>>> which need to get merged into the non-legacy docs somehow). >>>> Is this a good approach? Right now it seems like we need to focus on >>>> completing portions of this and cut a release of some sort so that we can >>>> have people look at usage, bindings and porting existing code. I'd love >>>> to >>>> get our website updated to filter just the APIs we plan to release soon. >>>> And then generate another section for the work-in-progress completion of >>>> interfaces... >>>> Hi, >>>> I told you on IRC already but I'm going to say it here publicly - >>>> personally I don't think it's a good idea to release APIs unless we're >>>> sure that it's really the API we want (i.e. it can be defined in Eolian >>>> once it's stable, it can be used for bindings and it's >>>> real-world-tested, i.e. we're sure of its practicality). I don't see any >>>> real benefit in releasing a subset of our APIs, only potential issues. >> >> We have been working on EFL interfaces for years now. Literrally. We have to >> do a release in the next 6 months. The main question is how to get there and >> have something good enough for everyone. >> My current take is that we finish cleaning up Efl_Core and Efl_Net for a beta >> release (which mean no further change except if something is really bad) and >> do an EFL release with that. This would make it possible for people who want >> to do binding to start working on it and report problem they have during 1.22 >> release cycle. This would be the only time we could still break our API in my >> point of view, but only if it is asked by binding developers. Finally for EFL >> 1.22, we will release an Efl_Ui component. and everything below will also be >> marked stable. >> >> ALL of eo/interfaces is already released as "beta". has been now for a very >> long time. how does this change anything? we have NEEDED to make changes that >> have broken what we have. i don;'t see this as any change to the current >> status.
They are delivered behind a BETA flag, not in beta. This is totally different. You can not rely on using eo, eolian or any of the new interface today at all. Try to write a binding in your spair time ? Give up, it is going to be broken for next release. Trying to use .eo to make your own objects, forget about it, it is going to be broken too. Basically, at this point only people that can spend their full time on it are the one keeping up with it (and barely). If we want to get more people eyes on this and get things settle it is time to stop moving dirt around like crazy. It is important to not forget that a core feature of this new API is that it is compatible with the old one. This is done to allow for a smooth transition path. It also means we don't need to release all of our API right away, we can turn on the light on a progressive path. I see value in stabilizing everything below Efl_Core.h and Efl_Net.h in the sense that we can maybe start to get people to look at what we have done, build bindings and give us feedback. Application can start to rely on some of the feature already of Eo. This will give us chance to improve the API that is yet to come. There will be mistake, their will be dead API, nothing is ever perfect and even if we wait another 6 months, a year to release this bits there would still be things that are not perfect. So let's start releasing small bits that are nearing being good enought and see where we are completely wrong, before we release everything and we end up with a massive amount of errors. Focusing our energy on releasing the lower bits will help us to get to a point where we can release the next layer. Cedric ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
