Adblock Plus and (a little) more
On rapid releases and version numbers · 2011-08-19 18:45 by Wladimir Palant
I’ve spent a little too much time arguing about rapid releases and version numbers in a German-language forum. In the end, I think that the benefits of rapid releases outweigh their disadvantages. It is indeed important for Mozilla to bring out new features faster, working more than a year on a release like it happened for Firefox 4 is unacceptable. Seeing Mozilla fall behind on caniuse.com and the like isn’t great, Mozilla shouldn’t become the factor slowing down progress on the web. Also, as an add-on author I like that release dates are predictable now, it allows planning in advance.
Still, there are also issues. One aspect that received particularly much criticism is that the version numbers are a lot less useful now. There is an idea floating around and I think that I like it quite a lot: instead of increasing the version number continuously the version numbers should relate to the release date. So Firefox 7 would become Firefox 2011.4 (4th major release in year 2011). Gecko version numbers could stay the same of course — or not. The advantages of this versioning scheme:
- The version numbers are relatively easy to remember again.
- One can see how current a release is just by looking at the version number.
- No false expectations because normally only the version part after the dot changes — so nobody will expect huge changes.
- The version numbers in this versioning scheme are higher so transitioning from the current versioning scheme is unproblematic.
I think that this would allow the version number to stay in the About dialog — removing it right now seems indeed premature to me. People don’t trust the rapid release process yet and feel the need to double-check the version number.
Comment [36]
Commenting is closed for this article.
gioni · 2011-08-19 19:27 · #
Good suggestion. I think Mozilla could also consider using the month for the second ‘digit’, like Ubuntu does. That would give (20)11.09 for Firefox 7.
This would also simplify checking if the latest version is installed…
tom · 2011-08-19 19:29 · #
that is the most sane and most conservative versioning idea i have heard about this: if releases are date based, make that explicit.
two small adjustments i would prefer even more: drop the 2000 from the version and also make the dot (point) releases month based. so your example would be “Firefox 11.9” for the firefox (to be) released in September 2011.
Reply from Wladimir Palant:
The advantage of having “2000” in the version is that it is obviously a date then. Nobody needs to complain: “Mozilla is crazy, they jumped from version 6 to version 11”.
Having the month as the second part of the version number has the disadvantage that version numbers are no longer continuous then. Not sure whether that is really important however.
mpopp · 2011-08-19 19:37 · #
I totally like this idea.
There are a few possible variations, like dropping the century part (20) of the year or to use the release month as second number (and maybe leave an increment third number for rare cases when there are 2 releases in the same month). But regardless which variation, it would definitely be better than what Mozilla is doing now.
But Mozilla should do the switch before the major version reaches the current year, which according to the current release cycle wouldn’t take long. Once the major version as passed that number, the switch would be much harder to do. But now is a good time for that.
Johan Sundström · 2011-08-19 20:39 · #
That’s an excellent suggestion. For an add-on I maintain off AMO (meaning I don’t get AMO’s automatic version bumps to em:maxVersion in its xpi manifest when automatic tests suggest my add-on is still fine on the next release), I have resorted to setting maxVersion to 4711.* (probably good through 2283 AD, if the scheme is stable and I think straight), because I don’t have the attention to devote every three weeks to testing if it works.
I would probably have set it to something more conservative with date-based version numbers based on my experience of how often breaking mozilla changes show up.
Jose · 2011-08-19 20:51 · #
There is some interesting discussion in here:
http://hacks.mozilla.org/2011/08/firefox6/
Aurora 9 is set to change the way that extensions are tested (being on by default).
Changing number versions to years/month is not bad, but would still trigger 2011.10.1 in bugfix releases that I guess would be a bit confusing.
Reply from Wladimir Palant:
I wouldn’t consider that discussion interesting – it’s full of non-constructive comments lacking proper argumentation, pretty much like any discussion on rapid releases unfortunately.
Markus · 2011-08-19 20:56 · #
Off-topic comment removed.
Reply from Wladimir Palant:
I’ll remove any bashing and flaming in the comments, I don’t want the same pointless discussion here. If you want my thoughts on add-on compatibility – I linked to Laura Thompson’s blog post. This blog post is explicitly about an entirely different topic.
Karsten · 2011-08-19 20:56 · #
You could use letters
2011.10.a
I think 26 Bugfixes should be enough for one Firefox-Version
Funtom · 2011-08-19 21:23 · #
In this fast paced development of web standards and Firefox release cadence in accordance, the current versioning system has really become obsolete. Using the date based numbering struck my mind as well. However, why number Firefox versions? What is a version? I’d drop this word altogether and number builds only as that’s what actually matters.
Also, I wonder when the e10s project allows for background automatic updates, so that no human interaction is needed. Or, was that idea abandoned altogether?
Percy Cabello · 2011-08-19 21:43 · #
I also like the YY.x versioning proposal, where YY is the year and x the number of release that year.
Also, we could make the switch next year, when Firefox should reach version 12 around the second/third quarter. From then on versions could be 12.x to avoid some of the confusion the switch.
Reply from Wladimir Palant:
It doesn’t look like this decision can wait until next year – that would mean ignoring confused users for another five months.
mpopp · 2011-08-19 23:34 · #
Looks like Asa Dotzler may support this system:
https://twitter.com/#!/asadotzler/status/104643377181622272
Hugo Heden · 2011-08-19 23:41 · #
> So Firefox 7 would become Firefox 2011.4 (4th major release in year 2011)… No false expectations because normally only the second digit changes — so nobody will expect huge changes.
Hmm, the “second digit” changing would mean 2011.4, 2111.4, 2211.4 — a release per century? Sounds cool.. but I think I’d expect pretty radical changes then :-)
Reply from Wladimir Palant:
Yeah, I thought that somebody would pick on that formulation. Changed it, now the nit pickers should be happy.
Leadcrow · 2011-08-20 03:20 · #
A date-driven versioning makes even less sense. Seriously, 2011.4 is better than the real version number (the normal one would still be available in about:support, keep note of that)?
Using minor versions for what are essentially minor software revisions served desktop apps well before, and remains the most appropriate course of action to take (4.0, 4.1, 4.2, then 5.0, etc). It takes a farfetched logic for Mozilla to claim not caring about version numbers, yet ramping those up artificially when such only has PR value (negative buzz has now become a boringly daily occurence).
Mozilla would better serve its purpose of making version consulting a necessity for only troubleshooting by focusing on a seamless bandwidth-efficient update system and keeping software versioning and breaking consistent with its APIs. Google’s Courgette could be put to good use here. – http://www.chromium.org/developers/design-documents/software-updates-courgette
Leadcrow · 2011-08-20 03:41 · #
Date-driven does not take multiple channels into existence, and without a channel switcher toggle (which was removed sometime ago). Updating to the latest build in your current or another channel
For web apps, this isn’t usually an issue as whenever made available (like for Gmail), experimental options are commonly accessible for the adventurous, and desktop apps like Chrome integrate experimental flags. Firefox follows neither approach (even for services), as new or experimental features are made only available for development channels and usability, deployment and actually meaningful improvements to a mobile-friendly browsing experience are overlooked(webP, SPDY, bandwidth economy for desktop and mobile like Opera’s Turbo – a major reason for their success with carriers and on mobile devices. The amount of bandwidth economising for those could alone fund Mozilla if/when Google shuts the dollar faucets).
Reply from Wladimir Palant:
The releases already are date driven. We already know that next release will be in 2011 (on September 27th to be exact), so we can name it 2011.4 from the start (or 2011.9 if we prefer the release month after the dot). And the version currently on the Aurora channel is due to be released on November 8th – version 2011.5 then (or 2011.11). The version number of the nightly channel would be 2011.6 or 2011.12. Multiple channels are not a problem, it only matters when the version will be released (which is known in advance).
Peter · 2011-08-20 03:41 · #
Thinking about versioning the web browser makes me think about something which we’ve essentially abandoned at this point, namely versioning the web server “content”. Modern websites almost without exception have content which changes continuously, but there’s no reason why – if we want to be able to trace failures back from bad client experiences to “reproducible cases” in QA – we should not include a “server state identifier” in the header of each HTTP response. This could be as simple as an integer indicating the epoch second (according to the webserver clock) when the HTTP request was received (so the state if the associated DB and static content can – at least in principle – be reconstructed from the server side change logs) or something as fancy as a CMS version ID. Then, when a user encounters an issue while browsing a website (or at least one which does not prevent the webserver response from being received) he/she can clearly and precisely specify everything that the owner/maintainer of the website requires in order to be able to reconstruct the issue.
Reply from Wladimir Palant:
I think that most web applications have revisions (or version numbers) – but those are only used internally, the user doesn’t need to care about them. The development team still needs to check which app revision a bug reporter was using (which is usually done by looking at the report date).
cuz84d · 2011-08-20 05:44 · #
This is one of the better suggestions, following YY.MM method, or YY.MM.x for security or minor fixes seems reasonable or try 2011.sp.x.DDD.HHMMSS (DDD being Julian days).
Even webapps can use versions to keep track of development like where I work. For instance consider using YYYY_BiWeek numbering for development. So each year there can only be 26 build release cycles. If there are bugs, we know which version introduced them or fixed them.
As far as the century comment, maybe next century we would not be calling it Firefox Suite, but there will be a new consumer product for the masses, without all extras and backwards compatibility without versions called WebfoxLive.
Ed · 2011-08-20 08:45 · #
Off-topic comment removed.
Reply from Wladimir Palant:
I’ll remove any bashing and flaming in the comments, I don’t want the same pointless discussion here. Don’t assume that something hasn’t been done just because you didn’t notice.
Asa Dotzler · 2011-08-20 11:43 · #
“People don’t trust the rapid release process yet and feel the need to double-check the version number.”
That may be the single most compelling argument I’ve read among the 1000 or so comments that I’ve been through since I filed the bug.
So, after a few more updates? The earliest it could change would be Firefox 9 anyway. That’s would be the 5th rapid-release update.
Reply from Wladimir Palant:
Maybe. The problem is that the discussion is happening now and people are doing it very emotionally rather than rationally. It isn’t a matter important enough to push it through.
skierpage · 2011-08-20 12:06 · #
A fine idea! I suggested it as soon as I heard of the new release tempo, e.g. http://matejnovak.com/2011/06/30/communicating-channels/#comment-63 (I suggested it earlier on Glazblog, but my comment never appeared).
Other folks: the six-week cadence is not monthly, so the second number shouldn’t be a month, so it isn’t YYYY.MM and there’s no leading zero.
Reply from Wladimir Palant:
As I commented above: it can still be the release month, it would merely mean that the versioning is no longer continuous.
Minok · 2011-08-20 18:41 · #
About the date-versioning: What if a release gets delayed?
Reply from Wladimir Palant:
There is no such thing as a delayed release with rapid releases. If a changeset (a feature or whatever) isn’t stable enough for the release it gets kicked out – will get into the next release then. The release still happens on schedule and contains all changes that are mature enough to be released.
Anonymous · 2011-08-20 19:03 · #
I don’t think the issue relates to who represents Mozilla, but the perception of how feedback gets treated. This decision came across as “Our UX person decided this”, with no opportunity to provide feedback on that point. Put that together with the prevalence of that behavior in other projects recently (e.g. GNOME 3), the responses that basically said “we considered that and still decided this was a good idea” with no explanation, and the various minor things like “all discussion must occur on USENET” (almost invariably used with controversial issues), and you get the perception that feedback will get ignored.
Reply from Wladimir Palant:
That’s not how Mozilla usually reacts. Nevertheless, comment spam in Bugzilla isn’t exactly welcome as Bugzilla is meant to coordinate work and not to facilitate lengthy discussions. It is indeed much better to use newsgroups or Google Groups – and to refrain from commenting if you cannot understand the arguments of the other party and then argument your opinion as well as offer alternatives (in other words, offer constructive criticism).
Anonymous · 2011-08-20 19:07 · #
Or, to put it a slightly different way, I think much of the backlash on this decision relates less to the decision itself (a bikeshedding issue, really) and more to people trying to figure out how to get involved in the discussion earlier in the decision-making process, which often seems to have started and concluded long before anyone in the community has heard about it.
pd · 2011-08-20 20:07 · #
All three reasons you use to support rapid-releases can be achieved with a sensible release schedule such as one set for every quarter, for example. Use of the year.month version numbering like Ubuntu could also help give version numbers some realism yet also allow Firefox to legitimately jump up to IE territory. Chrome’s versioning is just madness and should not be replicated.
Jeffrey · 2011-08-21 01:46 · #
I too like the purely date driven version numbers scheme of YYYY.MM. Also, different release channels aren’t a problem since all you need to do it add that on the number as in (channel)YYYY.MM.
Example:
Firefox (Beta)2011.09
njn · 2011-08-21 04:53 · #
“There is no such thing as a delayed release with rapid releases.”
I’m pretty sure that’s not true, that the process explicitly includes a final go/no-go decision at the end of the beta period. It’s possible that the beta might be judged unacceptable and no official release be made that cycle. Hopefully that’ll never happen, though, because it means things would have been really screwed up.
Rob Sayre · 2011-08-21 06:19 · #
“I’ll remove any bashing and flaming in the comments…”
It looks to me like the last sentence of your post is bashing and flaming. Maybe you should hold yourself to the same standard that you hold your commenters to.
Reply from Wladimir Palant:
I can send you links to news that made a point from these “Mozilla responses”. I can also forward you a reply from a journalist to my objection that these responses might have a point despite coming across as rude. And I can send you dozens of links to forum discussions where people feel that Mozilla doesn’t care about feedback. Unfortunately, this is no longer bashing or flaming – it’s a sad fact.
Dao · 2011-08-21 08:47 · #
“It’s possible that the beta might be judged unacceptable and no official release be made that cycle.”
This isn’t a problem. We’d go from 2012.1 to 2012.3, skipping 2012.2 — just like we would currently go from 9 to 11, skipping 10.
Also, perhaps this is obvious, but I’ll say it just for completeness: If we ever decide to do LTS and make 2012.1 such a release, maintenance releases could add and increment a third number.
Rob Sayre · 2011-08-21 18:13 · #
It doesn’t matter if you think what you’re writing is true, or even if it is true. It’s still bashing and flaming.
And it’s a thread about version numbers…
Reply from Wladimir Palant:
Good point… I removed that paragraph, I had my doubts about it anyway.
Tim Babych · 2011-08-21 21:09 · #
I very much hope your proposal in some form would be accepted. Flamewars erupting each 6 weeks are tiresome.
zob · 2011-08-22 00:36 · #
version numbers don’t actually matter much. Stop focusing on that.
Focus on what matters. There is no “its your opinion that version numbers dont matter”.
They do not, as a fact. What matters is a way to check what your website runs on and not getting popups for updates.
In other words you need to provide:
- a way for web devs to ensure their site runs under all versions of FF OR that everyone’s FF IS up to date (like Chrome) OR that and have a LTS.
- not having a delay for addons to be compatible, ever, yes its a big task. Enforce devs to use the stable API. I don’t know. The fact is that you have to do it or die.
- not having a popup to check them every 6 weeks, just check in the background
- Do not, I repeat DO NOT change the UI EVERY 6 WEEKS. If you UI team feels like they’re going to be thrown out if they don’t tweak the UI every 6 weeks then be it. People can’t change their behavior every 6 weeks because someone decided it’d be trendy.
And when you do change the UI make quadruple sure it won’t cause havok on a large majority of users.
Finally, lets talk about the domain highlight in the URL. If you’re going to think this is a good idea, at least implement it properly and highlight the whole domain before the /.
And if you wanted to do that to hilight only “paypal.com” when heh just highlight paypal. But don’t break other URLS for paypal thank you very much (like news.ycombinator.com ?)
2nd domain after the TLD is not always the important part of the domain.
caspy7 · 2011-08-22 06:11 · #
It looks like every new comment may be popping this blog post to the top of Planet Mozilla. I think I remember another developer having the same issue (which was resolved).
Reply from Wladimir Palant:
That’s because Planet is sorting posts by their update date – and I changed the post yesterday. I’ve set “lastmod=posted” in the database now, this should allow this post to get down on Planet.
ultravioletu · 2011-08-24 18:37 · #
Well, ATI introduced long ago a similar scheme for Catalyst drivers, and it works like a charm.
I’m all in for Wlad’s proposal.
elle · 2011-08-25 10:47 · #
your most recent update just took 50% of my cpu, fyi.
Jake · 2011-08-26 05:58 · #
I like all these date-based versioning proposals, but I think we should also integrate some sort of LTS/long-term support release into all this (mostly for corporate users). The first release of each year would be a LTS release which would be 2011.0, then the rapid releases could continue as 2011.1, 2011.2, etc. but corporate users could stay on 2011.0 until 2012.0 comes out. Security updates for normal (rapid) releases would occur while they are supported and could be represented as 2011.1.1 (first minor revision for 2011.1), 2011.4.2 (second minor revision for 2011.4), etc. Security updates for the LTS version (which would continue until the next LTS version) could be 2011.0.1, 2011.0.2, etc.
And, another thought… If we’re only including the last 2 digits of the year, we should just wait until rapid release 9 to implement the change (which is what would probably happen anyway) so then we could have the new system for the starting of the new year.
Reply from Wladimir Palant:
LTS isn’t a good solution. See http://www.squarefree.com/2011/08/25/improving-intranet-compatibility/ for better alternatives.
Juan · 2011-08-28 00:13 · #
If the numbering is problem, Why not go with Firefox 4.1, Firefox 4.2, Firefox 4.3, Firefox 4.4…?
Change to the large versions was only necessary for hype, advertising and give the impression that progress is as fast as Chrome. Then, numbered Firefox 4.x does not have this effect, but neither with Firefox 2011.x.
Sorry my bad English.
Reply from Wladimir Palant:
This suggestion has been discussed a number of times already. The main issue is that it makes things more complicated: there are no definitive criteria whether version 4.5 should be followed by 4.6 or by 5.0. The other issue is that we are already at version 9 and going back to lower version numbers isn’t possible, so that’s the earliest point in time when we can start using this version scheme (9.1, 9.2 etc.).
Levis · 2011-09-10 22:58 · #
Good post on the release cycle debate and as an individual I agree. Unfortunately, Mozilla’s future is in doubt at my school. As of now, all computers at my lab still use version 3.6, but when 3.6 is no longer supported by Mozilla, I don’t know if the technicians will continue supporting Firefox, preferring to exclusively use IE 8.
This will lock out all Mac users, and I would have to eventually downgrade by Ie 9 on my Windows machine. It doesn’t help that the application roll over rate is relatively high in my lab. Don’t really blame anybody for it b/c organizations do what they have to do, but this kinda sucks.
Cattleya · 2011-09-30 12:03 · #
Hi, I think theu should increase version slowly, example: 7.0 -> 7.0.1 -> 7.0.2 -> 7.0.x and rarely become 7.1, sometime they can jump version to 8.0 if needed, that will help addon developer a lot, no all add-on developer have time to update their add-on, example: ImgLikeOpera, developer is very busy and can’t check for update it, but it has so much user.