When do you stop teaching that old lolcat new tricks?
Here is a scenario that may be familiar to some Eclipse developers:
1. Write lolcats manager plugin using Eclipse x.y.
1.2 Build scripts for lolcats is written. Takes 2x time of writing lolcats.
2. Release lolcats for Ecilpse x.y.
3. Eclipse releases x.z to general public.
4. Lolcats is tested on x.z and it is compatible. (yay!)
4.2 Lolcats build scripts are modified to build against x.z.
5. You are now supporting Lolcats on x.y.* -> x.z.*
6. Users start sweating for bug fixes and new features only in x.z.
7. Brain starts hurting.
When do you stop supporting older Eclipse releases? There are some great things in 3.3 that simply are not available in 3.2, and the overhead in forking product that goes through building, testing, and documentation can be very expensive. Any advice on when to say when?
October 4th, 2007 at 9:33 am
IMHO… When version x.z.* is considered stable, and to support x.y.* causes excessive delays, or major code fragmentation to keep both in line.
However you must make sure you don’t alienate developers that can’t move to the latest version because it does not support their favorite plugin that is commonly used. Obscure things like a ADA plugin could be overlooked, but a SVN, CVS, plugin could be very painful to loose.
In the case of Java pre 1.5 support has been let go. However 1.5 is to some degree still on life support, and 1.6 is where the energy of Sun is going. 1.6 is stable and 1.5 compatible, meaning that if you are on 1.5, and had to move to 1.6 you would be ok. Actually if you moved from 1.3 to 1.6 you are not going to incur a great deal of pain.
My $.02
-Shawn
October 11th, 2007 at 1:03 pm
Support platforms, not packages. E.g instead of supporting Eclipse x.y, you support Ubuntu Dapper, or Ubuntu Feisty. Good stuff in new versions? Oh well — it doesn’t exist on your platform.
Anyelse else invites insanity.
October 11th, 2007 at 3:13 pm
Shawn and Russell, thanks for your feedback
. I think another factor is the age of your product. Our product is in beta now and has not really been released. I think we have more freedom in determining these requirements. And truly the problem isn’t just Eclipse versioning but Eclipse * Platform * OS .