I am interested in everyone's opinion on this matter: should EPIC remain usable in Eclipse 3.1.x?
The benefit of staying with 3.1.x is a potentially larger user base. I believe that upgrading to Eclipse 3.2 may appear unattractive to the current users of EPIC - an obligatory 100+ MB download not compensated by any apparent "killer features" (unless I am overlooking something).
The benefit of switching to 3.2 is developers' convenience and easier maintenance (which translates to the ease of implementing fixes/new features also). Where copy-paste is needed in the 3.1.x world, official 3.2 APIs might exist that permit a cleaner implementation.
I would especially like to hear arguments in favour of staying with 3.1.x based on an inability to upgrade for technical reasons.
here is a link to the new and noteworthy for 3.2:
while i agree 3.2 didn't add any killer features, i do feel that a lot of useful little things got added that i use on a daily or almost daily basis (and i need universal binary support for my macbook).
does eclipse have any way to force a runtime environment to check for backwards compatibility?
> does eclipse have any way to force a runtime environment to check for backwards compatibility?
I don't think so. Basically, you need to compile against 3.1.x jars. I guess you could import the required 3.1.x projects (with source folders) into a workspace using 3.1.x and then switch to 3.2 to work on this workspace.
No need to keep 3.1 compatibility. We all get dragged to using 3.2 eventually.
Yes, while 3.2 is all well and good I for one have a REALLY large and complex build environment. Switching to Eclipse 3.2 is NOT a trivial exercise and probably won't happen in our environment for quite some time. Certainly not until a number of issues are solved with other Eclipse components!
Thus I'd have to say that the sentiment "No need to keep 3.1 compatibility" just doesn't hold. For now any plugin that DOESN'T support 3.1.x we're just going to be stuck with the last version that DID. I expect the same is true for many developers on large projects/teams.
I'm using 3.2, and I'll probably go to 3.3 as soon as all the plugins I depend on support it. Backwards compatibility isn't a big deal for me -- I like to be near the edge (though not on it).
That said, I really sympathize with Alhazred. A few years ago I was stuck on RedHat 7.3, and I couldn't get the latest version of *anything*. I suspect that a large number of big IT shops get very tied to a specific version of Eclipse.
Eclipse appears to have settled on a yearly update schedule, so you can probably set a schedule of your own. Something like "we will continue to support the old version of Eclipse for X months after the new version ships. After that, we will discontinue support for the old version". I'd suggest six months as a reasonable number if you want to have a fairly rapid development pace, and nine to twelve (basically until the following release) if you want to be conservative.
Another option, a good compromise, would be to support the old version for four to six months, then pull a branch for the old version, and continue development on the new Eclipse version. When you fix a bug, fix it in top-of-tree, and if the patch applies cleanly (or mostly cleanly) to the branch, fix it there as well. Obviously the branch will fall farther and farther behind, but it's better than just dropping support entirely. That lets those of us who are hot for the latest thing have our fun, but doesn't leave people like Alhazred out in the cold. This is (roughly) the model that my company uses, and it works pretty well.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.