On Thu, 07 Dec 2017 13:45:51 +0000 Andrew Williams <[email protected]> said:
Without a guarantee of no changes then you don't provide anything stable to build on top of. It's no different to what we do now. We could just say "we think these interfaces are ok now - you can try using them but we might still break them" which is is not some special beta release. it's just providing a "we think its more stable now" assessment. but still if it's just what you were saying then what apps can be written using those api's - and will they be? > Why does it have to be black and white? releasing does not "guarantee no > changes", it probably does need to guarantee backward compatibility. The > challenge I see with our current situation is that we have published "beta" > which is not even close to stable and now don't have a clear next step to > get people involved. A "release candidate" might be an obvious step which > comes as part of a release plan, which is what I wanted to discuss. what we have is a release candidate so to speak that is clearly showing its state - it's not stable. trying to release something as stable that is NOT (call it a release candidate or whatever) is just being dishonest. > I think that EFL and our community is in a different place to where it was > years before ecore. We should learn from (everyone's) experience and figure > how to apply that to our current situation. Our current reality is that > companies with real products want to build on what we have. That's pretty > exciting I reckon. and they need the full stack done to build them. not just some small sub-bits. thus i point out what i did already... what apps with such a subset of api's (efl core/loop/net?). they can't even build things with efl.gfx. they need efl.ui and even then the efl.ui we are proposing means them losing several widgets they have used before etc. ... so that's already a sacrifice. > Until we have a release of the new API that people can actually start > relying on being somewhat stable we are expecting them to use only the old > API. In the meantime we have most active development on it's replacement. > We are basically saying "you can use the old stuff, but you'll need to port > later - or you can try and use the new stuff, which requires regular > updating to keep up". To me this looks like there is no practical way that > we can encourage new people to rely on EFL. This makes me sad. because that is the state we're in. like it or not we're there. the way out is to work on it, not to give people a false sense of security over a small subset of interfaces that we aren't even sure will stay stable. even a single abi change will be a "showstopper" for the example above (companies using efl). just 1 is a dead end. thus you either guarantee abi stability totally, or it's all bets off. > Should we instead figure when we might start releasing and set an > expectation to the public? Something like "come back in 2019"? well we hoped to finish in 2016, then by end of 2017 ... we have a better chance now as people are really focusing on it, but i actually suspect 2019 is a safe bet. mid 2018 might be "optimistic" and end of Q1 2018 is "totally crazy optimistic if the world all aligns right". > Andrew > > On Thu, 7 Dec 2017 at 10:37 Carsten Haitzler <[email protected]> wrote: > > > On Thu, 07 Dec 2017 08:54:05 +0000 Andrew Williams <[email protected]> > > said: > > > > so what applications can you build only with efl core and efl net and > > nothing > > else? > > > > zero applications will be built with these. it will not be tested. history > > tells > > me so. BUT it will tie our hands in making changes. so what value does this > > provide? none to any developers who know that the api is STILL unstable and > > changes might be made, unless we guarantee NONE will be... and then if > > NONE are > > broken, our hands are tied. > > > > i'm speaking from experience here. i made eet 1.0 long (years) before > > ecore, > > evas, etc. etc. ... and people didn't go using it. been there. done that. > > and > > by the time the others were ready i was already going "crap - i shouldn't > > have > > done that" because eet had to hold legacy file format support (and still > > does) > > that was deprecated already in efl before edje 1.0 was done. > > > > what we have now i think is the best we can do. > > > > > Hi, > > > > > > To say that it is publicly available behind a BETA flag is one thing, but > > > to call it a Beta Release is quite a stretch. To reference The Next > > > Generation Lexicon: "Beta phase generally begins when the software is > > > feature complete but likely to contain a number of known or unknown > > bugs.". > > > Given the current state of the interfaces I would say that to treat it > > like > > > that is exceptionally generous. I have never been anywhere where the > > > developers or users have been told "It's in beta - the APIs will change - > > > we don't care" which is common parlance around here. > > > > > > I think it's unfair to say that releasing a subset has "no value". The > > APIs > > > described allow you to build a complete application - albeit without a > > > graphical front end - which is a great start, even a solid foundation. > > With > > > a little more work we could have Efl.Canvas and Efl.Gfx in there to get > > > early access to the new graphical APIs. It seems that Efl.Ui is sinking > > the > > > most time and we are having to rewrite areas of it as the underlying > > > libraries change. Surely nailing the underpinnings and releasing them > > gives > > > us a stable platform to deliver on. > > > > > > Calling for release discussions seems required to focus us. As everyone > > > acknowledges we are a team spread very thin and if we continue to have > > > little or no direction for release we will continue to work on what is > > > interesting and not to wrap up an API that is actually usable and > > reliable > > > to anyone. > > > > > > Right now I don't think it's clear what we are trying to achieve. It > > would > > > be a death knell to our chances of being taken seriously if we once again > > > take 10 years to do a major upgrade. > > > > > > Regards, > > > Andrew > > > > > > On Thu, 7 Dec 2017 at 01:22 Carsten Haitzler <[email protected]> > > wrote: > > > > > > > On Wed, 06 Dec 2017 19:45:39 -0500 Cedric Bail <[email protected]> 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: [email protected] > > > > > > To: [email protected] > > > > > > > > > > > > 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. > > > > > > > > > This mean the remaining question is what is left to do for this. On > > my > > > > side : > > > > > - Remove reference to graphic interface when including > > Efl_Core/Efl_Net. > > > > > - Finish migration to Eina_Future > > > > > > > > > > If you have still some stuff on your plate, you should let us know. > > I do > > > > feel > > > > > that for helping Stefan we should open a ticket to track this last > > task > > > > until > > > > > a release. > > > > > > > > > > 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 > > > > > [email protected] > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > > > > > -- > > > > ------------- Codito, ergo sum - "I code, therefore I am" > > -------------- > > > > Carsten Haitzler - [email protected] > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > 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 > > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > -- > > > 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 > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > Carsten Haitzler - [email protected] > > > > -- > http://andywilliams.me > http://ajwillia.ms -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
