This has become a circular argument, as many do around here, vis: *) people are asking for us to try and agree on stable areas of the API so we can start testing it externally *) we won’t do that until there is proof that people are using our beta APIs (which are currently unstable). How can we break this loop?
I cannot believe that all of the new APIs are completely unstable until we release - that is basically a house of cards that we hope one day will become rigid. Some of what we have is more mature than other things - but every single API we add immediately goes into the BETA flag for next release.. If we cannot make any release in the way previously discussed then we absolutely should have some other way of illustrating our confidence in an API. Therefore an alternative I propose is to add an ALPHA flag (which is mostly what BETA feels like at the moment) where new Eo goes and those marked as BETA are the classes we feel could be eliciting feedback. This way we are able to show where we know we have not tested as much and can show a journey through creation, testing and integration into the BETA area. Without this we are just hoping that some day all our classes will be stable so we can roll a release... Andrew On Sat, 9 Dec 2017 at 12:48, Carsten Haitzler <ras...@rasterman.com> wrote: > On Fri, 08 Dec 2017 19:06:47 -0500 Cedric Bail <ced...@ddlm.me> said: > > > > -------- Original Message -------- > > > Subject: Re: [E-devel] What are we going to release? > > > Local Time: December 7, 2017 5:06 PM > > > UTC Time: December 8, 2017 1:06 AM > > > From: ras...@rasterman.com > > > To: Andrew Williams <a...@andywilliams.me> > > > Enlightenment developer list < > enlightenment-devel@lists.sourceforge.net> > > > > > > On Thu, 07 Dec 2017 13:45:51 +0000 Andrew Williams > a...@andywilliams.me > > > 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. > > > > I am thinking of a stronger commitment on our part here. Basically as I > said > > in my email above, if a binding doesn't report a real big problem with > what > > is under that RC umbrella, then we do not break it. > > unless it's "absolutely will not break at all" then it's really no better > in > the end. > > > I am afraid that for a lot of this lower level, we are now starting to do > > what we were doing before we release EFL 1.0. Trying to make it perfect > > without having ever spend the time to prepare a proper release. We need > to > > focus and get things out. > > > > > but still if it's just what you were saying then what apps can be > written > > > using those api's - and will they be? > > > > EFL apps already exist. They can get migrated to the new API. That is the > > main target of this release. > > other than some mechanical "sed work" like s/evas_object_del/efl_del/g ... > which buys nothing really useful... what is really going to be done? and > what > will this demonstrate to us or anyone else api-wise? not much. > > > >> 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. > > > > No, they don't ! Do not forget that EFL Eo API is compatible with the > legacy > > API and that this is especially done to allow people to migrate their > > application as time goes. Bits by bits. > > they absolutely do. e.g. c#. without the full stack it's pointless. and > they're > not going to migrate... except rewrite in a new language. you know that as > well > as i do. > > > [snip] > > > > >> 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". > > > > If we keep trying to release everything at once without commitment and > not by > > slice of useful bits, then sure we will still be at it in 2019 or maybe > even > > later. But we don't need to do so. Existing apps and existing bindings > won't > > stop working. The new API is designed to allow for a smooth transition. > It is > > designed to allow you to mix old and new together. This way, you can > already > > build a useful application by building with Efl_Core, Efl_Net and > Elementary. > > This is fine. > > it's not about "trying to release all at once". it's about not painting > ourselves into a corner. not limiting ourselves before we really need to. > > every release we do means we stop doing eo work and instead stabilize a > release. the more we do the more we push a final result into 2019. without > a > significant amount of the interfaces api available you won't really get > much, if > any, valuable feedback, and instead simply lose at least a few months of > work > time into release work. (1 month per release at least). > > i don't see how this gets us to our goal better or sooner than what we are > doing now. what i do see is: > > 1. getting there later > 2. not gaining anything really valuable in return for that delay > > but here's my take... the above is my advice, but delay-wise... i'm not > responsible. but mark my words that the goal that MATTERS - interfaces > that can > be used in BINDINGS like C#, C++, JS, LUA etc. will only get delayed ... > and > you know well enough how much a release delays. we have a whole mountain of > new coverity complaints. any eo api to be "stabilized for release" needs a > lot > of attention in review and actual use before that release goes out if you > want > any kind of stability guarantee to it. and you know full well that just > these > few api's are of nil use to the consumers of bindings like above until > there > is a LOT more there. > > but if you wish to take the risk and the blame when things get delayed... > you > go ahead. all i want is proof of actual use in the wild like you claim, > because unless there is such proof, no lessons will ever be learned from > this. > think of it as a "KPI". proof that the "stable beta api" is used without > the > current unstable beta #define and so on... in more than a few trivial > places. > > > 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 > > > > > -- > ------------- 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 > -- 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
