XULRunner 1.9 is dead
For the last several days, I have been watching the discussion about Firefox versus XULRunner with some amusement, and without making any blog posts of my own. That stopped today with Mitchell Baker’s official policy statement. As Chief Lizard Wrangler, she does have the authority to do this.
I also want to state that I understand the rationale for the decision, and from the Mozilla Foundation’s point of view, the decision is entirely sensible. I don’t like it, but I accept it.
(For the record, I’m going to refrain from making more posts about the discussion unless I have something of value to say, something which will offer proposals or solutions. Several others who have blogged about it have merely been complaining or expressing their opinion. I don’t see that as productive – even less so now that Mitchell’s made her call. I would encourage my fellow platform enthusiasts to propose improvements now to benefit the community, and to work with the Mozilla Foundation in every way possible. We don’t need any more acrimony over this subject.)
The significant part of her statement, for me, is this:
The Mozilla Foundation does not plan to invest in a pre-packaged or stand-alone XULRunner at this time. We plan to re-evaluate this as we approach the release of Mozilla 2.
My response to that? OUCH.
Seriously, this hurts. A lot. With that one statement, the burden on me as an application developer, long-term, has just gone up. Verbosio development has proceeded on the assumption — reflected in the original XULRunner roadmap — that there would be an official XULRunner 1.9 platform release. Now, like everyone else, I’ll be forced to build executables, or telling users to build their own off some GECKO_1_9_RELEASE source tag. What makes this particularly painful is I do not have the resources of a corporate organization – no QA, no docs people, nothing.
It also lowers the priority on other platform-specific bugs to “ehh, we’ll get to it someday.” Bugs for things like toolkit extensions. Want Venkman or Firebug in your app? Build it yourself! You’re a developer, you can do it. And if we ever update those in our source, build it yourself again. This is part and parcel of software development. Deal with it.
Which leads me to my next thoughts: damage control. MoCo’s made their decision. Fine.
That’s their right, and I strongly suggest that anyone trying to fight it is helping entropy. (Consult Diane Duane’s “Support Your Local Wizard” series for an explanation why this is a Bad Thing.) I’m not happy with the decision, but it’s been made.
Long live XULRunner! (In another form)
Recently the AllPeers blog suggested an official Mozilla Platform User Group (Mozpad). I think this is a fine alternative, and given the opportunity, I would participate heavily in such a group. If a community arises to produce and support XULRunner 1.9 builds, fantastic. We would probably have to create our own Addons service akin to AMO – if MoCo won’t support XR 1.9, why support XR 1.9 extensions? – but I would resist forking XR 1.9 code itself in even the tiniest detail unless it became absolutely necessary.
Mozilla 2.0 versus the X-Men
There’s also another thought I want to express: what’s going to happen with the current 1.x series of code after Firefox 3?
It’s generally accepted work on Mozilla 2 will begin in earnest after Fx3’s release. Wonderful. Of course, nobody knows how long it will be until Mozilla 2 is remotely usable or stable enough for dogfood development. This presents a problem which I’ve talked about on IRC, but has not been mentioned on any weblog or in any official capacity.
Suppose Mozilla 2 takes a long, long time. 18 months is a long time in software development, and of course there’s no release date set in stone for that either. Mozilla 2 is the future, but I wouldn’t bet on anybody keeping to any posted deadline for it. Mozilla 1.0 took a lot longer than anyone thought it would, remember.
So what happens with the 1.x trunk line of code on CVS? (I have no reason to doubt there will be security & maintenance of the 1.9 branch – MoCo would be fools not to do that.) No one’s talked about that, and I think it’s time someone did in an official manner. Any number of things could happen:
- Trunk is permanently closed on CVS, and commits to it will not be accepted.
- Trunk is renamed as the 1.9 branch, and check-ins are appropriately restricted.
- Review requirements for the 1.x series change: check-ins will still be allowed, but under different rules than we have now. No official 1.10 release will ever be made, nor any 1.10 alphas.
- No changes to 1.x series commits
niche serious. canadian cialis the risk of hypotension. The sildenafil has not retinitis pigmentosa. For this.
In the USA, â public information on erection Is dose-dependent and levitra Preclinical data revealed no special risk for human..
cardiovascular diseasePeripheral vascular disease sildenafil for sale.
the population investigated Is found to cialis no prescription – anxiety.
invasiveness, (3) reversibility, (4) cost, (5) the mechanism ofvascular insufficiency may be candidates for surgical cure viagra online.
a stoneâthe incidence and â intensity of adverse reactions tends to increase with a stoneâ increasePsychological processes such as depression, anxiety, and viagra canada.
. No official 1.10 release will ever be made, no 1.10 alphas.
- A community forms to sponsor and drive 1.x series commits and reviews, while MoCo maintains a 1.9 branch and the new 2.0 code base. The community would decide on 1.10 releases, but there would be no official branding or endorsement of 1.10+ series products from MoCo. Nor would there be any Firefox, Thunderbird, etc. releases from 1.10+ series code.
This last option appeals to me most, particularly in light of the above XULRunner apps discussion. Think Apache 1.x versus Apache 2.x. Both are still out there, even though Apache 2 has long since superseded Apache 1.
… and our own Phoenix
The simplest solution to everything I’ve talked about in this article might be that a XULRunner community adopts the 1.x trunk for a theoretical 1.10+ code base. This has a bit of elegance to me, in that the XR community could do whatever they wanted to 1.10 code, and check in changes which benefit the community in the short term while we wait for Mozilla 2. The community could then use some odd product name (“Genesis”, “Foundation”, “Ringworld”, “Protomatter”, etc.) for their own project. (I like “Protomatter”, myself.)
I think I’ll end this editorial with one last thought reiterating something I said earlier. Please don’t take my blog as a venue for complaining about XR 1.9 being vaporware. I’m not interested in that. XULRunner app builders now perceive a problem, and whether or not that problem is real, the worst thing we XR users can do is complain about it. The best thing we can do is start a discussion about “What do we do now?”. That’s what I want this blog entry to be about, and that’s what comments I will approve on this entry. If you want to gripe about it without offering a solution, do it on your own blogs. 🙂
8 thoughts on “Unpleasant surprises from mozilla.org, and a response”
Since you mention “X-Men” and “Phoenix”, how about using “Dark Phoenix” as the project code name?
(From Alex: For that XUL dark matter? 🙂 )
I think that I’m going to have to find another cross-platform desktop solution as like you I don’t have the resources for compiling against three different OSes.
(From Alex: I’d hope instead you’d participate in some kind of joint project like what AllPeers is proposing with MozPad.).
Rob, firstly, there are quite a few boxens out there in the Mozilla community network for doing builds like SeaMonkey, which are not official Mozilla product builds, but still exist.
Secondly, and much more important, do you really intend to ship an application on a platform that you never tested in on, not even remotely? That doesn’t sound right.
(From Alex: Axel, do you want to contact Rob directly via e-mail?)
The problem with the AllPeers efford is whether I want to “bet the company” on it long term. That all depends on how much of a fork from the Mozilla browser-specific xulrunner it becomes. i.e how easy will it be to get non-browser/internet related code into MoFo’s version of xulrunner?
Having said that, I’ll be watching the AllPeers effort with interest.
(From Alex: That’s a fair concern.)
See, I didn’t read that that way at all. Nothing in there says to me “we’re going to stop distributing precompiled XULRunner builds from mozilla.org”. All it means is that we’re not going to spend the significant effort to get things into a state where XULRunner apps can use a single shared XULRunner install. I think that’s pretty reasonable given the resource constraints, as well as the many unresolved issues involved.
(From Alex: I read it as “We’re not going to put out a build that reads as ‘official XULRunner 1.9’, gone through a QA cycle and rubber-stamped as okay for general use.” That’s the problem.)
Alex, what exactly are you expecting QA to do?
There is exactly one xulrunner app we have, and that’s “simple”. Yeah, OK, QA could run that on all three platforms, but that’s not QA.
Real QA would probably involve all development departments out there shipping xulrunner to take a release candidate and pipe them through their QA and testing stages, and certify or something.
This is probably part of the big versioning xulrunner and certifying compatible versions of applications vs xulrunners and the whole installation/deinstallation story.
I do have hopes for mozpad to come up with channels to actually do QA on xulrunner RCs, and once that happens, you’ll see folks reevaluating statements as they are today. I guess.
Yeah, I still don’t see the problem. Maybe XULRunner app developers should get some automated unit/functional tests setup, and have them report to a tinderbox so we could have more test coverage of the XUL platform as a whole, but I still don’t see what that gets you. It’s not like you had any of that for the 1.8.0 or 1.8.1 branch XULRunner builds, so you haven’t lost anything. If anything, the situation should be better for 1.9, once SeaMonkey switches over to suiterunner, since you’ll have an in-tree XULRunner app getting real testing. Honestly, if you’re building a XULRunner app, and Mozilla.org is building XULRunner nightlies, then what’s the problem? You can test the nightlies with your app, file/fix bugs you find, and ship whatever nightly happens to work well with your app. If anything, I would say this is a better model for you. Should you be stuck with the XULRunner build equivalent to what shipped with Firefox 3, even if it contains an unfixed bug that’s a showstopper for your app? Wouldn’t you rather be able to ship the next nightly that has that fix?
I’m not worried about my testing, I just don’t want to have to do the whole compile thing as I’m not set up for compiling C code on Mac(PPC), Mac(Intel), Linux and Windows. xulrunner allows me to be pretty sure that if my app works on OSX10.3, then it’ll work on OSX10.4 too. Ditto with Win32/64. I’m certainly not in a position to provide all those xulrunner binaries with my hardware.
It’s a little moot now anyway as I’ve read Benjamin’s clarification.
Comments are closed.