On Tue, 10 Dec 2013 08:19:34 +0100 Stefan Schmidt <ste...@datenfreihafen.org> said:
> Hello. > > On Tue, 2013-12-10 at 14:32, Carsten Haitzler wrote: > > On Mon, 9 Dec 2013 20:23:39 -0500 Michael Blumenkrantz > > <michael.blumenkra...@gmail.com> said: > > > > > On Tue, 10 Dec 2013 09:34:57 +0900 > > > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > > > > > On Mon, 9 Dec 2013 19:02:50 -0500 Michael Blumenkrantz > > > > <michael.blumenkra...@gmail.com> said: > > > > > > > > > On Tue, 10 Dec 2013 08:51:50 +0900 > > > > > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > > > > > > > > > On Mon, 9 Dec 2013 14:37:58 +0100 Stefan Schmidt > > > > > > <ste...@datenfreihafen.org> said: > > > > > > > > > > > > > Hello. > > > > > > > > > > > > > > On Mon, 2013-12-09 at 14:28, Stefan Schmidt wrote: > > > > > > > > Hello. > > > > > > > > > > > > > > > > On Mon, 2013-12-09 at 07:11, Jeff Hoogland wrote: > > > > > > > > > I'm not sure this is the case - just like Simon alpha4 builds > > > > > > > > > fine here. > > > > > > > > > > > > > > > > Really strange. I reviewd the commits that gone into rc1 and efl > > > > > > > > 1.8.2 but I can't see anything that broke this. Also its > > > > > > > > building fine for me and on jenkins. > > > > > > > > > > > > > > > > > At any rate I guess I'll try just disabling physics then. > > > > > > > > > > > > > > > > Please do. The physics module was not really maintained and Mike > > > > > > > > just removed it so it will be gone in the next rc and the final > > > > > > > > release anyway. > > > > > > > > > > > > > > > > Having it disabled manually for the rc1 should be ok for the > > > > > > > > people encountering this problem. Does that sound good for you > > > > > > > > guys? > > > > > > > > > > > > > > To avoid any more confusion on this Mike and I decided that I will > > > > > > > prepare a new rc1 tarball with the removal commit and upload it. > > > > > > > Will send a mail once its up. > > > > > > > > > > > > how about.. rc2? :) > > > > > > > > > > I don't want to drag this process out unnecessarily. > > > > > > > > there are still bugs being filed on phab... and i was more making the > > > > point that re-spinning a tarball with the same name/version is not a > > > > good thing. "which rc1 do you have?" "i don't know. rc1!". :) if there > > > > is a re-spin.. at least call it rc2... :) i could have done a "re spin" > > > > for 1.8.1 (another 1.8.0) as no code changed - it was a m4 macro doing > > > > the totally unexpected. but i had to do 1.8.1 :( > > > > > > > > > > there was no "re spin" as you call it. the tarballs sent to the list were > > > PREVIEW tarballs, and it was explicitly stated that they may or may not > > > have been the final release tarballs for those versions. you absolutely > > > could not have done the same thing, as you did not send your prepared > > > tarballs to any lists prior to doing the release. > > > > so i downloaded rc1. is mine fixed? :) you didn't answer that. how do i > > know if its the respin or not before i download it? > > > > even for rc's if there is a re-generate at sall it should get a new name for > > the archive. rc2, rc3, rc4 etc. imho > > It is clear what you mean. The problem is that we want to publish > tarballs _before_ we make them final. Even for rc or alphas. > > I agree that the way I updated the tarball was a bit problematic. I > see two ways out of this. a) a staging area where we upload tarballs > for testing and only move them over to the final destination once we > call them final or b) do as you suggest and increment the number > every time the tarball changes but keep it on the correct location. > > The later could also cause confusion when you have to bump the number > in to short time to allow more testing. Like you fixed one problem, > re-upload with higher number and do it again shortly afterwards for > another bug. You wanted to release 1.8.1 but end up with 1.8.3 within > a day before the actual announcement. We could do rc's for stable > updates as well. > > None of the solutions is really convenient. Need to ponder this. an rc is a release candidate. it's something that is published. its really just like a beta3/4/5/6 - ie just before release. it's published software one way or another... :) if you never publish it (upload it in a public place) then you don't have to increment it (eg go from 1.8.1 to 1.8.3 skipping 1.8.2 that you never published). i wouls say put the rc's in the same plase as alphas and betas and just like alpha and beta... do rc1/2/3/4/ etc. until you have zero more issues in an rc. -- ------------- 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
