Version number changes for Thunderbird

Mark Banner mbanner at mozilla.com
Wed Jun 1 19:24:07 UTC 2011


On 31/05/2011 03:40, Unicorn.Consulting wrote:
> This issue with sky rocketing version numbers will significantly 
> increase the 'another new version and this bug is not fixed' level of 
> dissatisfaction.   Users expect change with a new version, even 
> security and bug fix releases.  They might not be all that switched on 
> to exactly which version they have, but they do notice when they get 
> one and expectations are high that their personal problem will have 
> been addressed.
I can understand what you're saying, but isn't that really an issue with 
the rapid release process and not with whatever version number format we 
go with? I think the fact that new users already get security & bug fix 
releases and they know when they do, will mean they are already used to 
another new version turning up.
> The one thing about this that I have not seen discussed anywhere is 
> what it will do to addon comparability checking.
> Will add on developers also need to release a new version every 6 weeks?
> Will they simply start placing compatibility  entries showing 3 to 99?
> Will add on developers even bother?
I haven't covered this yet for Thunderbird, but the plan is to follow 
what Firefox do - they have already have a process in place where they 
look at add-ons for interface uses that have changed, and bump the 
add-on compatibility version if none are detected. I believe they will 
be looking at incorporating user feedback as well (I think I saw some 
references to the add-on compatibility reporter being used to aid this).

On the whole, I don't think we'd be breaking every extension every six 
weeks, so it is a lot less work for add on developers to do than first 
impressions might give. So far I believe the add-on coverage for FF 5 
from the automated bump is somewhere around the 75% to 80% mark, which 
IMO is a pretty good start.

Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20110601/d58220ef/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20110601/d58220ef/attachment.p7s>


More information about the tb-planning mailing list