Bugzilla – Full Text Bug Listing
| Summary: | Eclipse 3.2 support should be maintained to some degree | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Kevin Bracey <kbracey> |
| Component: | Mylyn | Assignee: | Steffen Pingel <steffen.pingel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P5 | CC: | mik.kersten, mjmeijer, r.karwowski, steffen.pingel |
| Version: | unspecified | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Kevin Bracey
Kevin: we do not currently have the resources to maintain another stream for Eclipse 3.2. Note that Eclipse itself only maintains the last-released stream (3.3) and the current development stream (3.4), and that we have the additional overhead of needing to support both the Eclipse 3.3 and 3.4 streams. Could you tell us more about your scenario and what tool you are using (if that's not private info)? The tool vendor could be encouraged to provide this support, also, it would be good to know what their 3.3 plans are in terms of determining priority. All in a similar scenario should vote for this bug. Okay, we're using Eclipse with embedded devices, and the C/C++ toolchain is based around ARC's MetaWare IDE. That is currently based on Eclipse 3.2 and a modified interim version of CDT 4.0. Because of their CDT modifications, it's not feasible to attempt our own shift to 3.3 - it's not just a matter of lack of official support. We're waiting for a 3.3-based release. We've been told to expect this before the end of the year, but who's to say? They're not bundling Mylyn, but it's a useful facility to add to the system. As a user of Eclipse more than a developer of Eclipse (although I'm starting to dabble), the prioritisation of 3.4 milestone support over 3.2 release support seems like a really odd decision. Out here in the "real world", people are using Eclipse as a development tool, and we're not tracking Eclipse's development versions - we're using the actual releases, as are the vendors we're working with. Thus we're not going to be bothered about 3.4 support until June 2008 at the earliest. And even then it will take time for vendors like ARC to catch up - on current progress, I'd imagine it's >=12 months until 3.4 support becomes an issue for our Eclipse users. But again, as I said, I'm only really expecting significant Mylyn bug fixes to be available for previous version of Eclipse, rather than all the latest ongoing new features. I've dealt with the Jira 3.10 issue thanks to your help (and added an entry to the FAQ covering it), and I've patched our copy to fix bug #206029. So this bug is more a statement of principle than being an immediate issue to me personally. I still feel the download sites could do with clarification for the benefit of others as discussed in the initial report though. Mik, this can also give us a chance to bring in some of the performance and well behaved issues in terms of network traffic like bug 196056: [performance] reduce frequency of repository configuration download. Maybe we should see whether enough people vote for this bug... From http://ianskerrett.wordpress.com/2007/10/31/how-fast-do-users-upgrade-to-eclipse-33/ >A couple people have asked me for data on how fast people upgrade to a new version of Eclipse or specifically 3.3. Unfortunately, ?data? is difficult to get on Eclipse and in general open source. However, here is what I can find: > >- In the first two months after the Europa release we had 2.8 million downloads. This does not equate to individual developers but I think it shows a lot of people have downloaded the new version. > >- We did an informal poll on EPIC, to see how fast people were planning to update. it showed that 90%+ would upgrade within 6 months. > >- BZ Media does an annual survey of Eclipse usage in Nov/Dec. time frame. Of those people that are using Eclipse, around 65% are using the latest version. > >Based on this, I typically estimate that 50-65% of the Eclipse community has upgraded to the lastest version within 6 months of release. I am interested if other people think this seems reasonable based on your experiences. Since filing this, I've just been presented with another vendor toolchain (Nokia's Carbide.c++ for Symbian) which is currently based on Eclipse 3.2... It looks like it is generally taking 6+ months for vendors of Eclipse-based systems to move to a new Eclipse release. As more embedded systems vendors start using Eclipse, their end users are going to be an increasing part of the Eclipse user-base, so the proportion of potential Mylyn users using old versions of Eclipse is surely going to increase. Eclipse 3.2 maintenance is out of scope of the Mylyn project. Commercial support for older Eclipse/Mylyn versions is available, see: http://www.eclipse.org/mylyn/support/ I think the original title is now obsolete, given elapsed time. I think it's now a case of "Eclipse 3.4 support should be maintained to some degree". Going back to my original argument, the commercial toolchain cycle is such that each version should be supported for 2 years. The bug was prompted by the fact that an Eclipse release (3.2) had its support dropped very shortly after release of the next version (3.3), but before a enough amount of time had elapsed for commercial toolchains to adopt 3.3. So the situation now is that commercial toolchains won't have had time to move to 3.5 yet, so don't drop 3.4 support, at least until 3.6 is out. We are currently discussing ending support for Eclipse 3.3 on bug 280832 for the next release. There are no plans to drop 3.4 support at the moment. Mik, can this bug be closed? Yes, it looks like we can close it, but could you put up a wiki section defining our policy? I think the following location is probably best: http://wiki.eclipse.org/index.php/Mylyn/Integrator_Reference#Building_on_Mylyn There's some overlap with: http://wiki.eclipse.org/index.php/Mylyn/Contributor_Reference#Checkout I have added a paragraph to the integrator reference and added a link to the contributor reference. |