Now that I’m actually getting paid to work on mozCC, we’re starting to discuss what’s necessary to call it 1.0. Generally, I think that there’s three things a 1.0 should represent (I say “should”, not “does”; we’re talking best practice here):
- stability: a 1.0 shouldn’t crash, cause corruption or otherwise seriously break things
- polish: a 1.0 should look complete, and look like the UI has actually received some lovin’
- longevity: more on that in a moment.
I think we’re well on the way to mozCC 1.0. The 0.8.1 release addressed issues with both stability and polish, and began to address longevity.
So what do I mean by longevity? I don’t mean to imply that a 1.0 is a stopping point for development, or that every feature has to be fleshed out and complete to be a successful 1.0. What I mean is that 1.0 should be a platform for users to trust and depend on. The recent release of 0.8.0 is indication that we’re not quite there with mozCC. For 0.8.0, I unfortunately reorganized the code in a way that I viewed as necessary, but which required me to recommend that users first uninstall previous versions before upgrading. This sort of extraneous requirement exposes more of the underlying mechanics than users should need to know about. They shouldn’t care that the code was reorganized: they should only need to care that performance and functionality improved. A few days after releasing 0.8.1, I have a few bug reports, but none relating to the upgrade process. This leads me to believe that we’re making progress on the longevity front.
So what needs to happen before 1.0? Here’s the short list:
* support the remaining methods of embedding RDF in HTML, as specified here * make the details UI Mac OS X friendly; it currently doesn’t look quite like it belongs * make sure linked RDF is working correctly; Wikipedia is the most visible test case for this * resolve outstanding lock-up issues; these are few and far between, but I do have two reported with 0.8.1
At this point, there’s only one thing we’re pushing out to post-1.0, and that’s support for RDF embedded in SVG, and viewed with the Adobe viewer (we already support RDF+SVG with native Mozilla SVG support).
If you have any suggestions, or think I missed something, “open a bug” or contact me.