On Sat, 21 Dec 2013 11:52:30 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Fri, 20 Dec 2013 21:35:32 -0500 Michael Blumenkrantz > <michael.blumenkra...@gmail.com> said: > > > On Sat, 21 Dec 2013 11:18:47 +0900 > > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > > > On Fri, 20 Dec 2013 20:22:45 -0500 Michael Blumenkrantz > > > <michael.blumenkra...@gmail.com> said: > > > > > > > On Sat, 21 Dec 2013 09:57:23 +0900 > > > > Cedric BAIL <moa.blueb...@gmail.com> wrote: > > > > > > > > > Cedric Bail > > > > > On Dec 21, 2013 12:54 AM, "Mike Blumenkrantz" < > > > > > michael.blumenkra...@gmail.com> wrote: > > > > > > > > > > > > discomfitor pushed a commit to branch enlightenment-0.18. > > > > > > > > > > > > > > > > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=5a6dcf17f322c52cf9745e6f83d9c11a6763f55c > > > > > > > > > > > > commit 5a6dcf17f322c52cf9745e6f83d9c11a6763f55c > > > > > > Author: Mike Blumenkrantz <zm...@samsung.com> > > > > > > Date: Fri Dec 20 10:50:40 2013 -0500 > > > > > > > > > > > > add separate elm version requirement > > > > > > > > > > > > elm versioning for stable series will be different than efl > > > > > versioning, so these are not the same. > > > > > > > > > > > > also now that the theme for enlightenment is distributed with > > > > > elementary, there may be (and is) a MAXIMUM usable version of > > > > > elementary > > > > > which will work with a given E version while I work to stabilize > > > > > various > > > > > api across the releases. as a result, e18 RELEASES will not be usable > > > > > with elm >= 1.9 (current git and beyond). > > > > > > > > > > Hum, why? We're supposed to have a stable abi for theme also. I may be > > > > > not involved enough with the development of elementary, but this > > > > > decision feel strange to me and is likely to displease distribution, > > > > > so > > > > > care to explain? > > > > > > > > just because the enlightenment edje theme got shoved into elementary > > > > doesn't mean its api is stable. it's pretty obvious reading it that > > > > there > > > > was little forethought or set direction and that it just evolved > > > > organically however people felt that it should at the time. as a result, > > > > it's a giant mess which needs to change. > > > > > > > > E18 broke theme compatibility with E17. this wasn't "as much" of an > > > > issue > > > > since the theme was distributed with the app. now that the theme is all > > > > distributed with elementary (a decision which, despite the memory > > > > savings, I still disagree with because of the exact reason raised here, > > > > though I also have no good solution for aside form having yet another > > > > required package which is just the combined theme), this means that a > > > > library release will contain api breaks in the theme for the as-yet > > > > unreleased app, which means that the app will then be incompatible with > > > > newer versions of the library. it's a chicken-and-egg problem without a > > > > good solution. > > > > > > > > given that "this is the way we're doing things", I'm choosing to not be > > > > held responsible for maintaining compatibility with previous versions > > > > for > > > > an indeterminate period of time into the future for an api which has > > > > NEVER been considered stable, just as the eo api has been released > > > > without needing to retain compatibility. > > > > > > actually arguing that "e breaks theme api and that's fine!" is an argument > > > many users would rail against. they invested mountains of time in themes > > > for e17 that now don't work (and it's not a trivial - move theme to the > > > elm > > > theme dir). > > > > while I can appreciate the time put in, the changes made between versions > > were not so substantial that themes cannot be easily updated. as I stated > > previously, there will be migration guides posted for each version to assist > > with this process. > > > > > > > > yes - elm broke theme api too between 1.7 and 1.8 - frankly it was > > > necessary as there was a total mess in many places, (lack of namespacing > > > for > > > one, and otherwise design flaws that frankly couldnt be fixed without a > > > break). > > > > same situation here... > > > > > > > > so maybe you should reconsider the idea that its ok to break theme api > > > every > > > release of e? i KNOW it's not good to do it to elementary. it's bad, but > > > there was little choice. perhaps focusing on doing things as much as > > > possible in a way that does NOT break is best. > > > > I'm not planning on breaking it in every release, and I'm certainly not > > setting out with that as one of my goals, but it does seem that the next few > > releases will have some breaks in order to fix or improve things. this is > > part of the process in moving towards what will eventually be a stable theme > > api that can be relied upon and doesn't break. that's the end goal here, and > > I think having some breakage along the way to achieve that is perfectly > > acceptable. > > > > I don't recall anyone ever claiming that the enlightenment theme api would > > be > > stable across releases; we only guaranteed stability there for minor > > releases. I'd like to change that, but it's going to take some time to get > > there. > > the problem is your previous statement comes off as a "i'm going to break > stuff > - deal with it, and i'm not taking responsibility - it's all the fault of > putting e's theme into elm!". > > merging theme into elm makes no difference there - a break is a break. trying > to blame-shift doesn't change that. trying to fob it off as "well i'm going to > break it anyway, thus i have a free-pass" does not change the results and > severity of such a break. > > the ONLY problem that a merge brings is that elm needs an update to get > updated > theme stuff for e. the rest is the same as before. what this boils down to is two problems: * default theme in elm may or may not be compatible with previous e releases, meaning they can't stay on older e releases forever if they want to update their elm. this is mostly the issue that I've been addressing, which is likely where the confusion is coming from. I'm okay with this. * user themes will break as theme api changes. I'm less okay with this, but I'm assuming that someone who has put in as much time as it takes to create a theme will spend the relatively small amount of time that it will take to update their theme on each release. compatibility can be maintained for plenty of things, but, as you said in regards to elm's theme, "frankly it was necessary as there was a total mess in many places". this statement applies here, and I think that avoiding breaking api just to appease current api users is likely to produce more issues for any future api users who will confused by how insane it is. > > > > > > > > > > tl;dr: don't mix live versions with releases. > > > > > > --- > > > > > > configure.ac | 9 +++++++-- > > > > > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > > > > > > > > > diff --git a/configure.ac b/configure.ac > > > > > > index 900d3fb..b4f86fe 100644 > > > > > > --- a/configure.ac > > > > > > +++ b/configure.ac > > > > > > @@ -96,6 +96,9 @@ AC_DEFINE(HAVE_ENVIRON, 1, [Have environ var]) > > > > > > efl_version="1.8.3" > > > > > > AC_SUBST(efl_version) > > > > > > > > > > > > +elm_version="1.8.2" > > > > > > +AC_SUBST(elm_version) > > > > > > + > > > > > > AC_CHECK_HEADERS([sys/timerfd.h sys/ptrace.h arpa/inet.h > > > > > > netinet/in.h]) > > > > > > > > > > > > dnl AC_CHECK_HEADERS(X11/extensions/shape.h,, AC_MSG_ERROR([Cannot > > > > > > find > > > > > X11/extensions/shape.h. Make sure your CFLAGS environment variable > > > > > contains include lines for the location of this file])) > > > > > > @@ -552,7 +555,8 @@ PKG_CHECK_MODULES(E, [ > > > > > > eina >= ${efl_version} > > > > > > eldbus >= ${efl_version} > > > > > > eio >= ${efl_version} > > > > > > - elementary >= ${efl_version} > > > > > > + elementary >= ${elm_version} > > > > > > + elementary < 1.8.99 > > > > > > emotion >= ${efl_version} > > > > > > $eeze_mount > > > > > > $udisks_mount > > > > > > @@ -574,7 +578,8 @@ efreet-trash >= ${efl_version} \ > > > > > > eina >= ${efl_version} \ > > > > > > eldbus >= ${efl_version} \ > > > > > > eio >= ${efl_version} \ > > > > > > -elementary >= ${efl_version} \ > > > > > > +elementary >= ${elm_version} \ > > > > > > +elementary < 1.8.99 \ > > > > > > emotion >= ${efl_version} \ > > > > > > $udisks_mount \ > > > > > > $eeze_mount \ > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
