- This topic has 13 replies, 8 voices, and was last updated 19 years, 6 months ago by Scott Anderson.
-
AuthorPosts
-
arjan.tijmsMemberEclipse 3.1 RC2 is out…
how many APIs have they changed this time? 😉
Scott AndersonParticipantWe 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.
well i thougth i heard that M8 they standarized the api and where not gona change it any more till next eclipse mayor version
snpeMemberI 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 rc1me for m7 have any problems with menu path definition, but it work – I check only db explorer and xml editors
regards
Paul HornParticipantWhen 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.
Scott AndersonParticipantWe’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.
binyanMember@fuzzbient wrote:
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.
Scott AndersonParticipantYes, 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.
Riyad KallaMemberI’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.
binyanMember@support-rkalla wrote:
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. 🙂
Riyad KallaMemberI 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 =)
soulsoluMemberB4
soulsoluMember@soulsolu wrote:
B4
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.
Scott AndersonParticipant4.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.
-
AuthorPosts