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