On 2-Aug-08, at 1:40 AM, Nick Hughart wrote: > Vincent Torri wrote: >> On Sat, 2 Aug 2008, dan sinclair wrote: >> >> >>> I'd say you're so eager to release something you're not thinking >>> about >>> the impression it gives. Changing things in a pre-1.0 is fine and >>> expected. Releasing a 1.0 and then breaking it or making major >>> changes >>> a few months down the road is a very bad impression. >>> >> >> I don't think that if we release a 1.0 soon, the next the next >> major release wiil be out in a few month. It will follow the same >> release process (some years) >> > > The problem is, the two issues that have come up that are being > considered as blockers are things that may affect how many people > want to use the EFL. So waiting 3-4 years after a disappointing > release may just push people away. We should at least try to > address the shortcomings now or people will either have to wait > years for the new release or get a release so soon that they have to > readjust everything. Either way, I'm sure they won't be happy. >>
It all comes down to when you're doing the 2.0 release. If you do a 2.0 release in a few months it looks like we just rushed a 1.0 out the door to say we had a 1.0. Major releases should last a few _years_. If we're seriously considering ripping out Embryo in a few _months_ that's a pretty good sign it isn't ready to be released yet. If we know we're going to rip out Embryo and we push out Edje with Embryo scripting just to remove it in the next release it isn't going to make people happy. They'll have to port all their themes to the new scripting language. We're better to wait until we have a foundation we want to work from to get there. >> >>> You're releasing something before it should be released just to give >>> the impression of a 1.0 for something that isn't 1.0. That leaves a >>> worse taste as a developer then holding off the release until we're >>> pretty sure what we've got will be it for the long haul. >>> >> >> Explain why you think that current efl can't be considered as 1.0, >> please I never said the EFL in general wasn't ready for a 1.0. I'm specifically talking about Embryo as we don't know it's future. Ecore could probably be released once ecore_data is removed and we could do a point release the splits it into separate packages. Evas, I don't follow the Evas discussions so I have no idea. Edje needs the Embryo question asked. Efreet could probably go as the API is stable and we fixup any caching issues in a point release. e_dbus, no idea don't use it. Eet is already 1.0. What this all comes down to, and what the major blocker for most of this is, is Eina. Pretty much everything in CVS will end up depending on it. Let's push to get that as a 1.0 first. >> It seems that you have the same opinion than raster has about >> enlightenment, that is enlightenment will be 1.0 when there will be >> no more improvements he will be able to think about. >> No, I don't think that. I just think picking an arbitrary library is silly. We should think about what needs to get released and what has a stable API. >> What the problem with doing releases ? It helps packagers and >> users, people that use commercially the efl are satisfied because >> they know they have a solid base set of libs they can work with. >> There is nothing wrong with doing releases. I just don't see the point of releasing for the sake of releasing when we already know we're going to break the API. >> >>> If you want to push something out the door, what about Efreet, or >>> getting Eina done then doing Ecore. We don't have to start with an >>> Embryo release. We don't have to push Embryo until we're ready to >>> push >>> Edje. Pushing Edje has to wait until we push Evas (which also has to >>> wait for Eina). >>> >> >> Heh, I would like to release all the efl as 1.0 (maybe after the >> eina move). Then, in a few years push the 2.0 release (for e18 ?). >> There are *lots* of stuff to do for a 2.0 release for evas and edje >> (i don't really know for ecore). About evas, you see the discussion >> between mainly Jose, Jorge and raster. About edje Gustavo told me >> that raster has huge plans about it. So why not writing edje 2 with >> these plans and with another scripting language than embryo when >> thee plans will be known a little bit more ? >> > I've made a similiar argument for EDJE, push it as is with embryo > and don't expect the flash/silverlight/etc crowd to jump on board > right away and make user interfaces. Use EDJE for what it can do > now and then in the future we can do a 2.0 release that adds the > extra stuff. But by that time, people may have throughly invested > in embryo and it may cost them quite a bit to change all that. > >> About efreet, I agree too that it should be out after the eina move. >> > > I'd like to see the icon caching improved personally since right now > it might as well not even be there, doesn't produce any significant > speedups. Isn't this just disabled at the moment? Sebastian would know for sure. dan ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
