facebook

Implications of a Milestone Release

  1. MyEclipse IDE
  2.  > 
  3. Installation, Configuration & Updates
Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #254435 Reply

    gregor42
    Member

    As an Software Architect, I’ve managed to get my organization to standardize on the Eclipse IDE.
    I’m working toward getting them to standardize on MyEclipse as well.

    Our runtime environment is Java 1.4.2. We have resisted moving to Eclipse 3.2 due to the Java 1.5 requirement. We don’t want developers to produce code that can’t run in out production enviroment.

    I see that the new milestone release requires Eclipse 3.2.

    Does this imply that, as has happened in the past, previous milestones will no longer be updated going forwards?

    MyEclipse is not the only optional Eclipse plug-in that we use. Part of why we are conservative with our upgrade cycle is to maintain compatability across-the-board. Will we be penalized in this way if we continue in this manner? 😥

    Do you take into account the industry trend for upgrade support when planning your releases?

    #254463 Reply

    Riyad Kalla
    Member

    1) Eclipse 3.2 doesn’t require Java 1.5 to run, please see the dev doc here: http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_2.html#TargetOperatingEnvironments
    2) The code Eclipse *produces* is completely independent of what JRE/JDK you are using to run it. This is set under the Project properties or Workbench properties under Java then Compiler. You set the compliance level for the code that the Eclipse JDT compiler produces all the way from 1.1 to 6.0. So for example, you can run Eclipse 3.2 using the Mustang (Java 6.0) nightly builds and work on a project that generates Java 1.1 code for an old IE-applet or something just fine.
    3) I don’t understand your question “as has happened in the past, previous milestones will no longer be updated”… Milestones are snapshots of our developmet moving towards a final stable release. You can think of them as “Betas”, it’s just in Eclipse-land the terminology of “Milestones” was selected. So no, we won’t ever step back to upgrade a beta release, we just keep releasing subsequent releases until the final stable GA release. Then we will issue bug fix releases to that while we plan and implement the next big release.
    4) Penalized: Why would you come to this conclusion? You can use any version of MyEclipse that you need to use. We will continue to build our product on the latest Eclipse platform as there are considerable increases in performance, memory usage and usability that go into each release that we need to stay ontop of to maintain compatability with the platform. Believe it or not, we still have 2 business accounts that are still using Eclipse 2.1 and MyEclipse 2.6.4 because company policy wouldn’t allow them to upgrade. I know it’s a pain when some killer feature comes out in a new release, but we cannot afford (developer-salary-wise) to pay for all that work to be back ported. And in a lot of cases because of the changes in the underlying Eclipse platform, it’s impossible to back-port that work.
    5) Upgrade trends: Not sure what you mean, we have to keep our product stable ontop of the most recent Eclipse platform releases since our product is built ontop of it, we maintain backward compatability in our tooling so yes we consider upgrades for enterprise customers very seriously… maybe you can restate what you mean?

Viewing 2 posts - 1 through 2 (of 2 total)
Reply To: Implications of a Milestone Release

You must be logged in to post in the forum log in