June 13, 2005 at 4:22 am #230937
Eclipse 3.1 RC2 is out…
how many APIs have they changed this time? 😉June 13, 2005 at 8:43 am #230945
We have yet to find out, but RC1 had a few.
Our current plans are to ship 4.0M2 on 3.0.2 followed by 4.0M2 on 3.1RCx, x being whatever RC build is current at the time. From that point on, we’ll likely begin developing on 3.1 as our primary platform while continuing to support 3.0.June 13, 2005 at 5:31 pm #231006
well i thougth i heard that M8 they standarized the api and where not gona change it any more till next eclipse mayor versionJune 13, 2005 at 8:28 pm #231010
I work with rc2 (gef,emf,ve,log4,spring-ide,hibernate-tools,webtools,me for m7 …)
It work fine – i don’t see changes from rc1 to rc2 – it was changes between m7 i rc1
me for m7 have any problems with menu path definition, but it work – I check only db explorer and xml editors
regardsJune 13, 2005 at 9:52 pm #231011
When will a 3.1RC2 compatible version be available? The current M7 version stops at the choose eclipse folder stage and won’t allow install with RC2 stating that it’s an incompatible version.June 14, 2005 at 8:58 am #231033
We’ll ship an RC2 (or RCx) compatible version of 4.0M2 shortly after we release 4.0M2 for Eclipse 3.0.2, which hopefully will be within a week or so.June 14, 2005 at 10:31 pm #231079
When will a 3.1RC2 compatible version be available? The current M7 version stops at the choose eclipse folder stage and won’t allow install with RC2 stating that it’s an incompatible version.
Yes, ME is quite anal about this, and could really use a laxative in this regard. A simple warning that this may produce abnormal results would suffice. Nonetheless, if you have ME installed in 3.1M7, then copy the links folder from 3.1M7 to 3.1RCx and YMMV.June 15, 2005 at 8:55 am #231096
Yes, ME is quite anal about this, and could really use a laxative in this regard
Actually, we’ve loaded up that bulid as source on the RC build and there are several compilation errors in it as a result of changes in Eclipse. So, I don’t think we’re being anal, just protecting our users from a bad experience with some features we *know* are broken. If you don’t happen to use those features then you won’t be impacted, but if you do it’s definately broken on the RC build.
Before you ask, no, I don’t remember which areas are problematic.June 15, 2005 at 11:17 am #231103
I’d like to point out that any users that wants to try our builds against different versions of Eclipse is more than welcome to, just download the manual install and follow the instructions, that is how our more *determined* users are running it.June 15, 2005 at 11:42 am #231111
I’d like to point out that any users that wants to try our builds against different versions of Eclipse is more than welcome to, just download the manual install and follow the instructions, that is how our more *determined* users are running it.
LOL! So we’re “determined” now. I suppose that’s better than some of the alternatives. All I’m saying is that I make sure our installers warn the user, but they don’t prevent him from doing what he is determined to do. For example with our installers I can install the Linux code on a windows machine. This is supported because you may have enough disk space for the software but not enough for the extraction AND the installation of the software, which can be as high as 3 times the install size for InstallAnyhwhere. I feel ME could loosen up in this regard, but then again if you don’t know how to work around it then you likely shouldn’t be doing it in the 1st place. 🙂June 15, 2005 at 11:47 am #231113
I feel ME could loosen up in this regard, but then again if you don’t know how to work around it then you likely shouldn’t be doing it in the 1st place. 🙂
This is really the approach we are taking, we make it really easy for users to install and run stable copies of everything, but when it gets to installing betas of things and potentially buggy situations we intentionally raise the barriers to entry just a hair. Bugs can be so damn frustrating at times to developers “in the trenches” that we don’t want to make it any easier for users to get into the position where they have a few hours to deliver a milestone and bam, they run into their first bug, run over here to the forums and then we have to say “Sorry that’s a bug with the beta, down grade please.”, that’s just like pouring salt on a wound.
So if we make the barriers to entry a bit higher, then the users that really want to do the beta releases in different combos can, but chances are they might run across some posts here in the forums first seeing some of the issues while trying to figure out how to get the two installed.
It’s like an intracate game of battleship =)June 25, 2005 at 12:28 am #231713
B4June 25, 2005 at 12:30 am #231714
Sorry – couldn’t help myself with the battleship reference above and all 😛
Any updates on the final cut of 4.0 on 3.02 so we can get our grits with the less-determined, lower barrier, bug free scripted-install version of ME for RCx ?
Your product rocks by the way.June 25, 2005 at 9:09 am #231719
4.0M2 for 3.0.2 is already public. 4.0M2 for 3.1 is now being tested by our QA Board and will be released this week, shortly after we can get our hands on Eclipse 3.1 final for one final look.
Eclipse 3.1RC2 is out
- This topic has 13 replies, 8 voices, and was last updated 18 years, 5 months ago by .
Viewing 14 posts - 1 through 14 (of 14 total)
Viewing 14 posts - 1 through 14 (of 14 total)