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
