Thunderbird versioning/Naming.

Axel Grude (Axel) axel.grude at gmail.com
Fri Jul 5 10:53:31 UTC 2013


On 05/07/2013 02:58, Josiah Bruner wrote:
> Well, I thought about this for a while, in fact, I even started writing several 
> paragraphs on why we shouldn't do what you suggested. However, as I thought about it 
> some more, I must agree with your points. The ideal solution would be to keep our 
> version number based on Gecko, while actually releasing a new product every 6 weeks. 
> Of course, that simply won't happen because of lack of resources and frankly, lack 
> of product. There would be no real point.
>
> Jumps from 17 to 24 to 31, etc, are very confusing for our users and may cause them 
> to lose faith in its' development. Even looking at the Thunderbird page causes 
> people to wonder. (Though the version of Thunderbird proceeding 24 should have some 
> large changes, and I want to redo the site then, which will help). Anyway, this kind 
> of jumping is just not beneficial in any way, so I agree that Thunderbird 20XY needs 
> to be the future.
There is only one thing which is missing here - if we follow this "Microsoft Model" of 
naming the product, we will need additional information visible to distinguish the 
maintenance releases; Following the example of Microsoft Visual Studio, this would be 
something like Tb 2014 SP 1 (Service Pack 1); this could than easily mapped back to 
our internal version numbers (23.0.1, 23.0.2 etc.). Also this assumes there is always 
only one "major" release per year, is this in sync with reality?



Also, since a lot of extensions use version comparator in order to be backwards 
compatible, so I assume everything will remain the same "behind the scenes"; we would 
just need a new separate function in nsIXULAppInfo to return the "user friendly" 
version number. (Obviously version and appVersion must remain unchanged)
>
> Thunderbird 2014 makes the product seem more developed, professional, and 
> trust-worthy. Of course, anyone with counter points should most definitely respond 
> in objection. I, on the other hand, second the motion for Thunderbird 2014. I assume 
> though that people from within Mozilla will really make the final ruling on this.

By the way, from a extension perspective the proportional number of users who use old 
(pre 17.0) versions is worrying; therefore I added a button to one of my addons 
(smartTemplate4) which is only visible for numbers < 17.0.6:



It offers the following explanation



and opens the about page on clicking Ok (goes straight to the update routine on 
Thunderbird 3.x, as the Help Menu item "check for updates..." did)

I feel strongly is that addons developers should also drive the update of their users 
by reminding them, as a lot of users are motivated (to lag behind) by trying to keep 
their addons compatible.

thanks,
   Axel

-- 
*Axel Grude*
Software Developer
Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie 
Keys, SmartTemplate4)
AMO Editor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20130705/1fedb86a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jgghefde.png
Type: image/png
Size: 125197 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20130705/1fedb86a/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dccaiiae.png
Type: image/png
Size: 37711 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20130705/1fedb86a/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hibaajch.png
Type: image/png
Size: 57045 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20130705/1fedb86a/attachment-0002.png>


More information about the tb-planning mailing list