On Wed, 06 Dec 2017 15:13:05 +0100 Daniel Kolesa <dan...@octaforge.org> said:

> 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.

I agree with Daniel here. Releasing just for the "need to release something".
These efl core/net API's rely on sharing concepts, interfaces etc. with the
rest of efl if we are to do it right, and that is still evolving as things
solidify. There is no value at all in releasing a subset like this. It's
useless without having a large enough set of epi's to usefully build
applications from top to bottom. Sure - ignore efreet, ethumb, eet etc. in eo
API for now. We could release eo API's without these once eo API is settled on
and releasable. But certainly not some tiny subset like above.

I'm currently working on efl_loop and related in an effort to pad out this bit
and have something for people to look and and reviews, comment on etc. But the
past week or so I've been busy with other things.

> However, I  do think it's maybe a good subset to aim for stabilizing
> first - maybe we could make use of it to set some kind of better
> direction to make our progress faster.
> 
> D5
> 
> > 
> > Thanks,
> > Andrew
> > -- 
> > http://andywilliams.me
> > http://ajwillia.ms
> > ------------------------------------------------------------------------------
> > 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
> 
> ------------------------------------------------------------------------------
> 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
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ras...@rasterman.com


------------------------------------------------------------------------------
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

Reply via email to