Hi, On Wed, Jul 29, 2015 at 1:54 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
> On Wed, Jul 29, 2015 at 5:41 AM, Michael Blumenkrantz > <michael.blumenkra...@gmail.com> wrote: > > On Wed, 29 Jul 2015 12:21:07 +0900 > > Jean-Philippe André <j...@videolan.org> wrote: > >> On Wed, Jul 29, 2015 at 9:20 AM, Christopher Michael < > >> cpmich...@osg.samsung.com> wrote: > >> > On 07/28/2015 05:29 PM, Mike Blumenkrantz wrote: > >> > > On Tue, Jul 28, 2015 at 5:15 PM, Cedric BAIL <cedric.b...@free.fr> > >> > wrote: > >> > >> I have learned that commit > 5cb6cdbc5e1a13ea0262e155983b494e6519abde in > >> > >> efl tree break all the past version of Enlightenment. Without > patching > >> > >> Enlightenment itself, there is no way to fix this apparently. We > are > >> > >> now very close to the release and this is breaking one of the few > >> > >> application we have. I think this patch should be reverted asap. > >> > > > >> > > I am not advocating in either direction, but I will need to > immediately > >> > do > >> > > another E19 release as well as make changes in E-git if this is > reverted; > >> > > internal windows will remain permanently unclickable in this case > since > >> > > hacks were added to work around these changes. > >> > > >> > Also not advicating in either direction, but this DID cause US a lot > of > >> > HEADACHE because it changed expected behaviour. IMO, a bit late in the > >> > process to introduce a major change like this. This SHOULD have been > >> > done earlier in the cycle and had time to flush out. > >> > >> Sorry to sound so naive, but did you report those behaviour breaks? Why > >> work around instead of fixing EFL? > > > > These sorts of things happen regularly. Every time I update Elementary > on my > > desktop, I find new "bugs" in applications that I've written as a result > of > > behavior changes. We usually say that such changes are justified because > "it's a > > bug fix" or "the previous behavior was broken", but these are still > behavior > > changes which break applications. > > Ok, this is something that should not happen, but did in the past. > That's why I have been advocating for proper behavior checking of the > whole stack for a long time and that is finally moving forward with > exactness starting to get some love, but much more is needed (still we > also need espion to move forward on this). One of the thing we should > not let slide, is to report any future breakage as soon as it happen, > ideally we should be able to record a trace for an exactness tests > suite and make sure that doesn't get broken. > > >> If I understand correctly, E 19.6+ are compatible with EFL < 1.15, but > only > >> E from git is compatible with EFL 1.15? > > > > <E19.6 requires EFL < 1.15 due to behavioral changes > > > > E19.6 requires EFL >= 1.15 because I didn't get the backwards > compatibility > > right on the first try > > > > E19.7 requires EFL >= 1.11 (as in E19.0 release) > > > > E-git requires >= 1.15 for API usage > > Ok, now I am super confused ! So if we revert the change from current > EFL tree, E19.7 should be fine as it is compatible with previous > version of EFL. Will E-git still be fine ? If it wil, we can just > revert and have the situation fixed. > > >> Then we have a problem IMHO since our release cycles are not in sync, we > >> can't just go and break everyone's E by updating EFL. This includes > forked > >> versions of E, as well as other applications using ecore events > directly. > > > > I don't think the release cycle timelines are an issue here, especially > > considering you're citing forked versions of E which we have no control > over. > > > > If "E19" compatibility is something that we are concerned with, the 19.7 > > release from last week resolves those issues and will have already been > out for > > long enough that any distributions which ship EFL should have already > picked it > > up by the time the final 1.15 release occurs. > > That's not how it should work. Any release of EFL should not break a > released software that use the expected behavior of EFL. Especially > when we only have so few of them. > Yeah, we're talking about EFL here, which apparently broke behaviour in such a way that it broke existing apps (E). > If we're concerned with theoretical other applications which may be > affected by > > this, I can produce a 19.8 release to remove this codepath in E prior to > the > > 1.15 release, assuming that a decision is made which provides me with > enough > > time to do so. Ideally anyone who has picked up 19.6-7 will also pick up > a 19.8 > > release in time for users to not be affected by any issues. > > I may misunderstand your sentences here, but the issue is in EFL 1.15 > which is breaking existing software not in E. So I believe we should > remove the breakage from EFL, and if by reverting things from EFL we > have E fixed then we are good. That's the main question here. > Is there a precise path to observe the original bug? I'm running E 19.5 with EFL from git but can't see anything special. Or did you actually fix ecore to restore similar behaviour as before? -- Jean-Philippe André ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
