The Problem with Major Revisions
Commercial, and Open Source applications periodically bump their Major version number. When done for none marketing reasons, this usually means something major changed. And sometimes it also means that there will be incompatibilities with the previous version. Take Python for instance, the bump from 2.x to 3.x caused all the print statements to blow up your script until you changed them. These incompatibilities are perfectly acceptable and in fact desirable as it means that things are evolving.
The problem is however that the older version stay around much longer than you might have wanted.
A lot longer.
Look at the Perl community. Perl 5 is living on strong even though it has been 9 years since work on Perl 6 started. I don’t think Perl 5 will ever die at this point.
Selenium is about to undergo a similar revision bump with the merger of it and WebDriver. This is either wildly succeed, or cleave the community in two. I’m obviously invested in its success, so here is what I think might need to happen to make the transition to and adoption of Selenium 2 as successful as it can be.
- Backwards Compatibility – While certainly not nice from an architectural perspective, the 1.x API needs to be replicated in 2.x. With the cleanup-up API, things can certainly be marked as deprecated, but they need to work.
- Migration Documentation – There needs to be a mapping of the 1.x to 2.x API so people writing new scripts know what to use. I know the Se docs team is already merging in the WD docs into the main suite, but I think we need to go one, or two steps further.
- Use Case Documentation – The Se documentation is getting really good, but tends to be less ‘how do I do X?’. Things like Flash, Data Driving, Analysis, Performance testing using Se should all be in the core doc set; and using Se 2 syntax.
- Vendor Discussions – I’m lumping any organization that incorporates Se into their product; commercial or not. We need to get everyone working with the new code, not just people who grab it from the main site. This means working with the Cucumber, Robot Framework, WebTest, PushToTest teams to get their products stable with Se 2.0.
- Not Ignore 1.x – Its not going away. We can’t just say ‘its fixed in 2.x’, even if it is. As painful as it might be, bugs will have to be fixed in 1.x until we remove all the excuses people have for not moving to 2.x. Leadership positions are tenuous, if we break ‘click’ in 1.x, it needs to be fixed there. Now, I’m not suggesting it stick around forever, but until 2.x is kicking ass it certainly does.
Of these five issues, I think the fourth one is going to be the biggest challenge. I don’t even know if there even a partial list of who to contact about it (maybe I’ll do some ‘competitive analysis’ in the next week or so).
Version bumps are part of everyday life with any product or technology, but managed poorly they can cause more damage to the product and community than the benefit that caused the bump in the first place.