The usual explanations about why version numbers are what they are
in CentOS apply.
However, taking off my systems hat for a minute and put on my software
development hat, in the case of Eclipse I wouldn't suggest using the
one available via RPM anyway. During software development just as
you want to control the versions of your jars, libraries, etc of your
application stack, you should probably independently control the
versions of your IDE, as changing IDE versions is as intrusive as
changing library versions, and it is rarely convenient to schedule
that kind of change concurrently with an OS upgrade.
So in the case of Eclipse, I would worry less about why the CentOS
one is out of date and instead pick a relatively recent version,
download the *.gz, have the developers extract it to local disk,
and run it that way.
Slightly OT, but while you're at it, I'd suggest also keeping your
workspaces separate for each Eclipse version and project, thus
something like:
~/src/eclipse-workspaces/indigo32/project1
~/src/eclipse-workspaces/juno64/project2
~/src/eclipse-workspaces/juno64/project3
Plus, Eclipse is always better with a workspace that is local disk.
Devin
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
