Should EPIC stay compatible with Eclipse 3.1?

jploski wrote on Sat Aug  5 17:20:10 MEST 2006:

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.

jgangemi wrote on Sat Aug  5 19:17:28 MEST 2006:

here is a link to the new and noteworthy for 3.2:

http://download.eclipse.org/eclipse/downloads/drops/R-3.2-200606291905/new_noteworthy/eclipse-news.html

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?

jploski wrote on Sat Aug  5 19:40:06 MEST 2006:

> 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.

gnuboi wrote on Mon Aug  7 20:20:41 MEST 2006:

No need to keep 3.1 compatibility.  We all get dragged to using 3.2 eventually.

tharter wrote on Mon Oct  9 17:09:22 MEST 2006:

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. 

kridx wrote on Fri Nov  3 07:48:53 CET 2006:

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.