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. > 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. -- Cedric BAIL ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
