Community
Participate
Working Groups
Mylyn is currently released for Eclipse 3.3, and 3.4 milestones. The last 3.2-compatible release was Mylyn 2.0. Many users are using proprietary toolchains derived from Eclipse, and it takes time for the vendors to update to a new Eclipse release. While waiting for the vendors to catch up, their users cannot yet update to Mylyn 2.1. For tools like Mylyn that integrate into commercial toolchains, I would expect there to be ongoing support for both the current and previous full releases - ie Eclipse 3.2 and 3.3 at present, rather than dropping support for version 3.2 the moment 3.3 comes out, and focusing solely on the current release and the next beta. We're not all in a situation where we can track the latest core Eclipse release, let alone milestone build. Therefore if any significant bugs are found in Mylyn 2.0, fixes should be made available to Eclipse 3.2 users somehow, preferably until Eclipse 3.4 release. Either by issuing minor updates to Mylyn 2.0 when required, or by maintaining Eclipse 3.2 compatibility on current Mylyn development. For the core, I suspect issuing minor patches would easier. And as the core doesn't interface to the outside world, there's less chance of new problems arising anyway. For connectors and similar, maintaining Eclipse 3.2 and 2.0 compatibility may be straightforward. If the latest versions of subcomponents like connectors are actually Eclipse 3.2 and Mylyn 2.0 compatible, this needs to be documented on the download web pages. As they currently read, it would never have occurred to me to even attempt installation of a current JIRA connector on top of a Mylyn 2.0 installation - the per-version download sites led me to assume that versions were closely coupled, and all download URLs are marked as "Eclipse 3.3 and 3.4" after Mylyn 2.0. (Download site declared dependencies also need to be carefully checked). Current bugs affecting me personally on Mylyn 2.0/Eclipse 3.2 are: bug 205995: JIRA connector doesn't support JIRA 3.10 (fix definitely needs to be available) bug 206029: Task Repositories pop-up half functional (not worth issuing a patch for this alone, but if one were to be issued, this fix should go in, as it's a highly visible UI problem with an easy fix)
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.
