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