On behalf of all who contributed, I am very proud to announce availability of Sapphire 0.5.3 release. This maintenance release includes bug fixes for issues raised by adopters. Adopters of previous 0.5.x releases can expect full backwards compatibility. No migration guide is being published.
This release is also available in the Juno SR1 repository. Look for Sapphire under Application Development Frameworks category.
A lot has been said about Eclipse 4.2 performance and stability in the past few weeks. Unfortunately, the community feedback is not positive. This is undoubtedly very difficult to hear for developers who worked so hard for several years to deliver the new platform. This feedback is also difficult to hear for those of us working on layered technology and products. No one in the Eclipse community likes to see what is happening to the reputation of their favorite IDE.
So where do we go from here?
Some have chosen the path of blaming the community. If only there were more people contributing to the platform over the last few years, we wouldn’t be in the current predicament. Now that we are here, if only more contributors would step forward and “give back” to the platform, we would get to a better place quicker. There is no doubt, that more active contribution to the platform would yield measurably better platform, but have calls for more contribution ever yielded the desired result? Why should we expect a different result now?
Calling on the community to “give back” to the platform is frankly insulting and makes about as much sense as calling on the platform team to give back to WTP or EMF or GEF. After all, where would Eclipse be without those toolsets and frameworks. Eclipse achieved its current place in developer mind share not by having the best platform than the competition, but through the breadth of solutions. I don’t know of a single Eclipse.org project or a third-party solution that couldn’t benefit from more resources, so lets stop with guilt casting. The community contributes to success of Eclipse in a variety of ways.
Is 4.2 SR1 or SR2 or 4.3 going to be better? I don’t doubt it, but is it reasonable to ask users to to put up with performance, stability and polish issues for however long it takes for 4.x to match 3.x in these areas? The technology landscape is littered with once-successful projects that have undertaken lengthy re-writes while neglecting the user need for stability.
On the opposite side of the spectrum, some have called for Juno to switch to the more stable 3.8 stream. This isn’t a good solution either. Cut off from the distributions and the common repository, the 4.x platform will have a hard time gaining user base necessary to stabilize. Absent users, the stability would not meaningfully improve for Kepler or the year after that. Effectively, this road abandons the investment made in the 4.x stream. Some may say they don’t care if 4.x stream dies, but no technology remains relevant by stagnating, so this road is just as risky in the long term as the current one.
The community cannot afford the reputation hit of stabilizing 4.x stream by forced adoption and the community cannot afford to abandon the investment made in the 4.x stream. So what is there left to do? I propose that until 4.x stream reaches the stability and polish of 3.x stream, the simultaneous release process should produce both 4.x and 3.x distributions along with the corresponding repositories. It is human nature to seek that what is new and shiny, so there will be developers eager to use 4.x stream. As long as there is a reasonable fallback, we can make progress without antagonizing the user base we all have spend so much time and money building.
Let’s take a deep breath and choose the safe road. We have all invested far too much in Eclipse to risk it by driving too fast on the switchbacks with no guard rails.
If you have an opinion on this proposal, leave a comment in the bugzilla entry that I opened.
Posts
All Comments
