On Mon, 9 Dec 2013 15:11:31 +0100 Stefan Schmidt <ste...@datenfreihafen.org> said:
> Hello. > > On Mon, 2013-12-09 at 20:48, Simon wrote: > > On 12/09/2013 08:33 PM, Stefan Schmidt wrote: > > > Hello. > > > > > > On Mon, 2013-12-09 at 20:05, Simon wrote: > > >> On 12/09/2013 05:40 PM, Stefan Schmidt wrote: > > >>> Hello. > > >>> > > >>> On Sun, 2013-12-08 at 14:58, Jeff Hoogland wrote: > > >>>> Just wanted to confirm emotion generic players isn't getting a 1.8.1 > > >>>> release. > > >>> Confirmed. Emotion generic players had not a single commit since > > >>> 1.8.0. Nothing to release. > > >>> > > >>> regards > > >>> Stefan Schmidt > > >> From a packagers perspective it would be great if we could keep the > > >> efl, elementary and evas/emotion_generic_loaders version numbers the > > >> same even if there are no changes, the same as we did for the 1.7 tree. > > >> I'll leave it for you guys to decide though. > > > I was pondering about that. For 1.7.x we had way more tarballs for one > > > release. Due to the merged efl tree this really got down. > > > > > > Would you expect emotion generic player release tarballs for 1.8.1 and > > > 1.8.2 even when not a single commit hit that repo? > > > > > > We can switch back to that model but I'm not a fan of doing "empty" > > > releases just to stay in sync for the version number. > > > > > > It would only heppen from 1.8.3 though. Skipping a minor release for > > > everything but efl. IT will always be out of sync with e18 in any > > > case. > > > > > > In sumarry I have no hard feeling in any direction. :) > > > > > > regards > > > Stefan Schmidt > > > > > I wasn't much of a fan of the empty releases at first either, but > > realistic the enlightenment foundation libraries are efl, elementary and > > e*_generic_loaders, its just some components are built separately > > because its easier and others due to licensing. From a user perspective > > particularly in regards to filing bugs it makes it easier if they all > > follow the same versioning, especially if efl and elementary are out of > > sync. > > We did it with 1.7.x and its seems to make packagers life easier as > well as versions for bug reports, etc. So be it. From 1.8.3 I will do > collective releases for efl, elm, evas and emotion generic loaders. > Even if the specific tarballs have no changes. we did it for efl < 1.8 because we had like 12+ packages and we often depended on a bugfix in one efl pkg to make another work right. now our lives are MUCH simpler. :) the generic loaders + players pkgs are small and dont get a lot of traffic. we likely could merge those into some single "efl-loaders" tree with ease. that'd be wise as emotion and evas are now together too in efl. at this stage elementary will be a hard nut to merge primarily because of elm_web and webkit. we need to get our support straight there. what we do is undecided at the moment, but the likeliest scenario is that we import an entire webkit tree into EFL. it's basically the only way to make it work - specially cherry pick the right webkit version that happens to work and then import it and every now and again when a known tested webkit tree update works.. import that wholesale. and for those who don't know. webkit-efl requires efl. elementary optionally requires webkit-efl. we can't merge elementary and build elm_web support if elm is merged into efl as webkit-efl can't be built until you have efl and not efl requires webkit-efl... :S -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
