Following several discussions, the Thunderbird drivers have decided to adopt the same version numbering scheme that Firefox has adopted <http://mozilla.github.com/process-releases/draft/development_specific...> following the transition to the rapid release process. This also means that Thundebird will match its version numbers with the gecko version numbers.
Whilst we could have kept the same numbering system, or adopted a different one, we felt that matching Firefox would make it clearer for developers as to which version of Thunderbird was based on which gecko/Firefox version.
We'll also be de-emphasising the version numbers in our releases, it is much more important that users keep up to date with the latest security and stability fixes, and of course latest improvements, than being concerned that a jump from one number to the next is a big jump.
Therefore, we will be renumbering the current work in progress releases as follows:
* Thunderbird 3.3 (aka Miramar) will become Thunderbird 5.0 (based on gecko 5.0). * The builds which will be produced from comm-aurora (where we merged to last Tuesday), will become Thunderbird 6.0. * The builds from comm-central which are currently numbered 3.4a1pre will become Thunderbird 7.0.
Does that mean that patches recently merged into comm-miramar will have to merged into comm-aurora as well for them to be taken into account for Thunderbird 6?
jonathan
On Thu 26 May 2011 08:06:50 PM CEST, Mark Banner wrote:
> Following several discussions, the Thunderbird drivers have decided to > adopt the same version numbering scheme that Firefox has adopted > <http://mozilla.github.com/process-releases/draft/development_specific...> > following the transition to the rapid release process. This also means > that Thundebird will match its version numbers with the gecko version > numbers.
> Whilst we could have kept the same numbering system, or adopted a > different one, we felt that matching Firefox would make it clearer for > developers as to which version of Thunderbird was based on which > gecko/Firefox version.
> We'll also be de-emphasising the version numbers in our releases, it is > much more important that users keep up to date with the latest security > and stability fixes, and of course latest improvements, than being > concerned that a jump from one number to the next is a big jump.
> Therefore, we will be renumbering the current work in progress releases > as follows:
> * Thunderbird 3.3 (aka Miramar) will become Thunderbird 5.0 (based on > gecko 5.0). > * The builds which will be produced from comm-aurora (where we merged > to last Tuesday), will become Thunderbird 6.0. > * The builds from comm-central which are currently numbered 3.4a1pre > will become Thunderbird 7.0.
> Whilst we could have kept the same numbering system, or adopted a > different one, we felt that matching Firefox would make it clearer > for developers as to which version of Thunderbird was based on which > gecko/Firefox version.
I outright doubt that this is solving any real-world problem.
Chrome-angst-driven version number frenzy might make (very limited, IMO) sense for a competing browser, but do users really care about the Gecko version of their _mail_ client?
I do understand, though, the assumed marketing "value" of pairing the version number with FF. I just think it's nonsense. ;-)
> We'll also be de-emphasising the version numbers in our releases,
> Mark Banner aber hob zu reden an und schrieb: >> Whilst we could have kept the same numbering system, or adopted a >> different one, we felt that matching Firefox would make it clearer >> for developers as to which version of Thunderbird was based on which >> gecko/Firefox version. > I outright doubt that this is solving any real-world problem.
> Chrome-angst-driven version number frenzy might make (very limited, IMO) > sense for a competing browser, but do users really care about the Gecko > version of their _mail_ client?
> I do understand, though, the assumed marketing "value" of pairing the > version number with FF. I just think it's nonsense. ;-)
>> We'll also be de-emphasising the version numbers in our releases, > Well, you may do, but will the users? ;-)
As you mention users don't care about the Gecko version of their mail client. Majority of users don't pay attention to versions at all -- OS, browser, mail client, other software.
It'll be "Thunderbird" in our marketing going forward rather than "Thunderbird [version]"
First of all, thanks to Wayne for pointing me to this interesting and informative communication channel, and hi to everyone known and unknown.
It's unfortunate I'm starting out here with a critical post, furthermore it's somewhat emotional (blame it on the late time of the day, and reduce the severity of the message accordingly after reading), but anyway, here's my comment on the version number changes planned for TB:
My whole-hearted agreement on Karsten's scepticism against the new versioning intentions.
Thunderbird is not known for moving very fast in its development, and where it has moved fast (as in the case of the new global search, or maybe the quick filter bar), it has left a desert of UI problems and desiderata that are unsolved to this day. My suspicion is that the merging of MozMessaging with MozLabs with the intention of developing new phantastic products to cover the full range of today's communication channels will not exactly improve the manpower situation for core Thunderbird without bells and whistles, on the contrary. The language in that announcement seems way too defensive to be fully trusted... Fast development trains will only help if there is sufficient manpower to actually develop, instead of a dependence on God-sent volunteer contributors like Jim who is currently restoring big chunks of one largely neglected and deteriorated core functionality of TB: attachments UI. While other deteriorated corners will continue to languish, although concepts and suggestions are mostly out on the table.
What I am trying to say is that exploding version numbers that do not reflect actual feature changes that are relevant to the user (which Gecko versions are not) will add insult to injury from a normal users perspective: While version numbers will be rocketing skywards under the new scheme (starting with that leap from 3.x to 5), there will be nothing tangible in terms of bugfixing and UI-improvement / added features that will actually justify those leaps from the traditional user's viewpoint where version number changes reflect visible improvments. It is a myth that version numbers could be de-emphasised, as many of our users are very aware of version numbers: from painful experience widely documented in the forums like getsatisfaction, bugzilla etc., they have come to associate version number changes in Thunderbird with more complications of workflow, continuous erosion of screen real estate, and other dangers which overshadow some of the significant improvements that co-occured.
> we felt that matching Firefox would make it clearer > for developers as to which version of Thunderbird was based on which > gecko/Firefox version.
That main reason for changing the versioning system starts out all wrong because it focuses on the small no. of developers rather than the large userbase. Furthermore, I suppose people that are actually capable of developing Thunderbird will also be able to find out Tb's gecko version even if it's not in the title of the product. If I am not mistaken, finding out the version number used to be as simple as going to help > about. Why do I care that much? Maybe because it's another one of those changes in Thunderbird that the world does not need, and that may turn out to cause more harm than good to an already endangered product. Imagine Thunderbird 10 and we may still not be able to search all of our address books in one go - wouldn't that be weird?
I'm not always as pessimistic, most of the time I just find lots of bugs and suggest improvements, and than patiently wait for some years till someone picks up on it (or even acknowledges the problem, as in so many unbelievable keyboard/focus issues). A good indicator of such hopeful occasions used to be an increase in the version numbers of the product. With the new suggested versioning system, the version numbers would become largely meaningless to that regard. Yes, version numbers do matter and they should not be abused for technical reasons that are irrelevant for the larger parts of the userbase, or for a false understanding of marketing that bloats version numbers without improving the product at the same pace.
Otherwise, with respect to matching FF's version no: So far I naively assumed that the difference in version numbers between FF and Thunderbird actually had some truth value with respect to development (due to differences in manpower, resources, you name it). It may not be wise to cover up that truth by pretending to be what we are not.
> Mark Banner aber hob zu reden an und schrieb: >> Whilst we could have kept the same numbering system, or adopted a >> different one, we felt that matching Firefox would make it clearer >> for developers as to which version of Thunderbird was based on which >> gecko/Firefox version. > I outright doubt that this is solving any real-world problem.
> Chrome-angst-driven version number frenzy might make (very limited, IMO) > sense for a competing browser, but do users really care about the Gecko > version of their _mail_ client?
> I do understand, though, the assumed marketing "value" of pairing the > version number with FF. I just think it's nonsense. ;-)
>> We'll also be de-emphasising the version numbers in our releases, > Well, you may do, but will the users? ;-)
For what it's worth: Normal Thunderbird users who are non technical are totally confused by the difference in version numbers between Thunderbird and Firefox AND often can't tell whether they are running Thunderbird or Firefox.
Therefore from a support point of view, aligning thunderbird and firefox version numbers and releases is a good thing because it will lead to less user confusion.
> First of all, thanks to Wayne for pointing me to this interesting and > informative communication channel, and hi to everyone known and unknown.
> It's unfortunate I'm starting out here with a critical post, > furthermore it's somewhat emotional (blame it on the late time of the > day, and reduce the severity of the message accordingly after > reading), but anyway, here's my comment on the version number changes > planned for TB:
> My whole-hearted agreement on Karsten's scepticism against the new > versioning intentions.
> Thunderbird is not known for moving very fast in its development, and > where it has moved fast (as in the case of the new global search, or > maybe the quick filter bar), it has left a desert of UI problems and > desiderata that are unsolved to this day. My suspicion is that the > merging of MozMessaging with MozLabs with the intention of developing > new phantastic products to cover the full range of today's > communication channels will not exactly improve the manpower situation > for core Thunderbird without bells and whistles, on the contrary. The > language in that announcement seems way too defensive to be fully > trusted... > Fast development trains will only help if there is sufficient manpower > to actually develop, instead of a dependence on God-sent volunteer > contributors like Jim who is currently restoring big chunks of one > largely neglected and deteriorated core functionality of TB: > attachments UI. While other deteriorated corners will continue to > languish, although concepts and suggestions are mostly out on the table.
> What I am trying to say is that exploding version numbers that do not > reflect actual feature changes that are relevant to the user (which > Gecko versions are not) will add insult to injury from a normal users > perspective: > While version numbers will be rocketing skywards under the new scheme > (starting with that leap from 3.x to 5), there will be nothing > tangible in terms of bugfixing and UI-improvement / added features > that will actually justify those leaps from the traditional user's > viewpoint where version number changes reflect visible improvments. It > is a myth that version numbers could be de-emphasised, as many of our > users are very aware of version numbers: from painful experience > widely documented in the forums like getsatisfaction, bugzilla etc., > they have come to associate version number changes in Thunderbird with > more complications of workflow, continuous erosion of screen real > estate, and other dangers which overshadow some of the significant > improvements that co-occured.
>> we felt that matching Firefox would make it clearer >> for developers as to which version of Thunderbird was based on which >> gecko/Firefox version.
> That main reason for changing the versioning system starts out all > wrong because it focuses on the small no. of developers rather than > the large userbase. Furthermore, I suppose people that are actually > capable of developing Thunderbird will also be able to find out Tb's > gecko version even if it's not in the title of the product. If I am > not mistaken, finding out the version number used to be as simple as > going to help > about. Why do I care that much? Maybe because it's > another one of those changes in Thunderbird that the world does not > need, and that may turn out to cause more harm than good to an already > endangered product. Imagine Thunderbird 10 and we may still not be > able to search all of our address books in one go - wouldn't that be > weird?
> I'm not always as pessimistic, most of the time I just find lots of > bugs and suggest improvements, and than patiently wait for some years > till someone picks up on it (or even acknowledges the problem, as in > so many unbelievable keyboard/focus issues). A good indicator of such > hopeful occasions used to be an increase in the version numbers of the > product. With the new suggested versioning system, the version numbers > would become largely meaningless to that regard. Yes, version numbers > do matter and they should not be abused for technical reasons that are > irrelevant for the larger parts of the userbase, or for a false > understanding of marketing that bloats version numbers without > improving the product at the same pace.
> Otherwise, with respect to matching FF's version no: So far I naively > assumed that the difference in version numbers between FF and > Thunderbird actually had some truth value with respect to development > (due to differences in manpower, resources, you name it). It may not > be wise to cover up that truth by pretending to be what we are not.
> Best wishes and greetings,
> Thomas
> On 27.05.2011 00:06, Karsten Düsterloh wrote: >> Mark Banner aber hob zu reden an und schrieb: >>> Whilst we could have kept the same numbering system, or adopted a >>> different one, we felt that matching Firefox would make it clearer >>> for developers as to which version of Thunderbird was based on which >>> gecko/Firefox version. >> I outright doubt that this is solving any real-world problem.
>> Chrome-angst-driven version number frenzy might make (very limited, IMO) >> sense for a competing browser, but do users really care about the Gecko >> version of their _mail_ client?
>> I do understand, though, the assumed marketing "value" of pairing the >> version number with FF. I just think it's nonsense. ;-)
>>> We'll also be de-emphasising the version numbers in our releases, >> Well, you may do, but will the users? ;-)
Roland MoCo Tanglao wrote: > Normal Thunderbird users who are non technical are totally confused by > the difference in version numbers between Thunderbird and Firefox AND > often can't tell whether they are running Thunderbird or Firefox.
That's a joke, I hope?
> Therefore from a support point of view, aligning thunderbird and firefox > version numbers and releases is a good thing because it will lead to > less user confusion.
If you can't differ between two programs with *different* version numbers, you take away the version number to make it easier to differentiate?! Huh? Reality check, please?
If you're serious, you should tie program version numbers to OS version numbers, since those particular users won't understand the difference anyway.
> We'll also be de-emphasising the version numbers in our releases, it > is much more important that users keep up to date with the latest > security and stability fixes, and of course latest improvements, than > being concerned that a jump from one number to the next is a big jump.
FYI, that *is* an important information, though. There are developers and companies with big deployments which need to know how much work they have to expect, due to API and profile file changes, UI changes etc..
Question: Will we end up with Thunderbird 15 in a year's time (and TB 25 in 2 years), or what's the plan? _______________________________________________ tb-planning mailing list tb-plann...@mozilla.org https://mail.mozilla.org/listinfo/tb-planning
> What I am trying to say is that exploding version numbers that do not > reflect actual feature changes that are relevant to the user (which > Gecko versions are not) will add insult to injury from a normal users > perspective: > While version numbers will be rocketing skywards under the new scheme > (starting with that leap from 3.x to 5), there will be nothing > tangible in terms of bugfixing and UI-improvement / added features > that will actually justify those leaps from the traditional user's > viewpoint where version number changes reflect visible improvments.
I think it may be useful to remember that a version number is just a number assigned to a particular version of software. Historically, we have overloaded that version number to imply the size of an upgrade from one version to the next, and that's what we're challenging.
> It is a myth that version numbers could be de-emphasised, as many of > our users are very aware of version numbers: from painful experience > widely documented in the forums like getsatisfaction, bugzilla etc., > they have come to associate version number changes in Thunderbird with > more complications of workflow, continuous erosion of screen real > estate, and other dangers which overshadow some of the significant > improvements that co-occured.
If you read what's been said about the Firefox version bump, there's certainly indications that the general majority of users don't know which version they are on. I know of non-tech savy people like this (though obviously a very small sample), and they are just happy to keep up to date.
However, like you say, many users are aware of the version numbers. What they will learn over the first two or three of the new style releases is that the version number is no longer going to be indicative of the changes in that version.
> Otherwise, with respect to matching FF's version no: So far I naively > assumed that the difference in version numbers between FF and > Thunderbird actually had some truth value with respect to development > (due to differences in manpower, resources, you name it). It may not > be wise to cover up that truth by pretending to be what we are not.
We're not pretending, we're changing the meaning of the version numbers, and our marketing will need to reflect that. We are going to be able to say that we're rolling out a new release of Thunderbird, which contains these features, and the latest security updates. IMO that's much better than saying we're releasing version N and folks assuming the amount and size of changes in the release based on the increment from the previous version number.
> Does that mean that patches recently merged into comm-miramar will > have to merged into comm-aurora as well for them to be taken into > account for Thunderbird 6?
Yes, if we've not got them on comm-aurora already, we'll need to make sure that happens. At the moment, the number of patches in that situation is small, and I actually think that most of them have made it onto aurora anyway.
I'm hoping to get the tracking flags etc set up this week.
> On 26.05.2011 20:06, Mark Banner wrote: >> We'll also be de-emphasising the version numbers in our releases, it >> is much more important that users keep up to date with the latest >> security and stability fixes, and of course latest improvements, than >> being concerned that a jump from one number to the next is a big jump.
> FYI, that *is* an important information, though. There are developers > and companies with big deployments which need to know how much work > they have to expect, due to API and profile file changes, UI changes > etc..
I think if they assess the amount of worked based on the version number increment, then that is going to give a very poor indication of the amount of work. For example, with the old system, what if we did a whole-number version bump, but only actually implemented one big new feature without changing other APIs, and without affecting their integration. They would assume a lot of work, when in fact it would be very little.
Likewise, with a minor version bump, we could have changed a lot of APIs, but not actually implemented many new features, and they would then have a lot of work to do.
Surely it is better to give the new release some assessment (e.g. a quick test, brief investigation into the code), rather than rely on a version number increment?
> Question: Will we end up with Thunderbird 15 in a year's time (and TB > 25 in 2 years), or what's the plan?
For
what it's worth:
Normal Thunderbird users who are non technical are totally
confused by the difference in version numbers between Thunderbird
and Firefox AND often can't tell whether they are running
Thunderbird or Firefox.
Therefore from a support point of view, aligning thunderbird and
firefox version numbers and releases is a good thing because it
will lead to less user confusion.
Having that confusion clearly demonstrates something. Pitch you
answer to a very slow 4 year old.
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.
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?
Matt
...Roland
On 11-05-30 3:09 PM, Thomas Düllmann wrote:
First of all, thanks to Wayne for pointing
me to this interesting and informative communication channel,
and hi to everyone known and unknown.
It's unfortunate I'm starting out here with a critical post,
furthermore it's somewhat emotional (blame it on the late time
of the day, and reduce the severity of the message accordingly
after reading), but anyway, here's my comment on the version
number changes planned for TB:
My whole-hearted agreement on Karsten's scepticism against the
new versioning intentions.
Thunderbird is not known for moving very fast in its
development, and where it has moved fast (as in the case of the
new global search, or maybe the quick filter bar), it has left a
desert of UI problems and desiderata that are unsolved to this
day. My suspicion is that the merging of MozMessaging with
MozLabs with the intention of developing new phantastic products
to cover the full range of today's communication channels will
not exactly improve the manpower situation for core Thunderbird
without bells and whistles, on the contrary. The language in
that announcement seems way too defensive to be fully trusted...
Fast development trains will only help if there is sufficient
manpower to actually develop, instead of a dependence on
God-sent volunteer contributors like Jim who is currently
restoring big chunks of one largely neglected and deteriorated
core functionality of TB: attachments UI. While other
deteriorated corners will continue to languish, although
concepts and suggestions are mostly out on the table.
What I am trying to say is that exploding version numbers that
do not reflect actual feature changes that are relevant to the
user (which Gecko versions are not) will add insult to injury
from a normal users perspective:
While version numbers will be rocketing skywards under the new
scheme (starting with that leap from 3.x to 5), there will be
nothing tangible in terms of bugfixing and UI-improvement /
added features that will actually justify those leaps from the
traditional user's viewpoint where version number changes
reflect visible improvments. It is a myth that version numbers
could be de-emphasised, as many of our users are very aware of
version numbers: from painful experience widely documented in
the forums like getsatisfaction, bugzilla etc., they have come
to associate version number changes in Thunderbird with more
complications of workflow, continuous erosion of screen real
estate, and other dangers which overshadow some of the
significant improvements that co-occured.
we felt that matching Firefox would make
it clearer
for developers as to which version of Thunderbird was based on
which
gecko/Firefox version.
That main reason for changing the versioning system starts out
all wrong because it focuses on the small no. of developers
rather than the large userbase. Furthermore, I suppose people
that are actually capable of developing Thunderbird will also be
able to find out Tb's gecko version even if it's not in the
title of the product. If I am not mistaken, finding out the
version number used to be as simple as going to help > about.
Why do I care that much? Maybe because it's another one of those
changes in Thunderbird that the world does not need, and that
may turn out to cause more harm than good to an already
endangered product. Imagine Thunderbird 10 and we may still not
be able to search all of our address books in one go - wouldn't
that be weird?
I'm not always as pessimistic, most of the time I just find lots
of bugs and suggest improvements, and than patiently wait for
some years till someone picks up on it (or even acknowledges the
problem, as in so many unbelievable keyboard/focus issues). A
good indicator of such hopeful occasions used to be an increase
in the version numbers of the product. With the new suggested
versioning system, the version numbers would become largely
meaningless to that regard. Yes, version numbers do matter and
they should not be abused for technical reasons that are
irrelevant for the larger parts of the userbase, or for a false
understanding of marketing that bloats version numbers without
improving the product at the same pace.
Otherwise, with respect to matching FF's version no: So far I
naively assumed that the difference in version numbers between
FF and Thunderbird actually had some truth value with respect to
development (due to differences in manpower, resources, you name
it). It may not be wise to cover up that truth by pretending to
be what we are not.
Best wishes and greetings,
Thomas
On 27.05.2011 00:06, Karsten Düsterloh wrote:
Mark Banner aber hob zu reden an und
schrieb:
Whilst we could have kept the same
numbering system, or adopted a
different one, we felt that matching Firefox would make it
clearer
for developers as to which version of Thunderbird was based
on which
gecko/Firefox version.
I outright doubt that this is solving any real-world problem.
Chrome-angst-driven version number frenzy might make (very
limited, IMO)
sense for a competing browser, but do users really care about
the Gecko
version of their _mail_ client?
I do understand, though, the assumed marketing "value" of
pairing the
version number with FF. I just think it's nonsense. ;-)
We'll also be de-emphasising the
version numbers in our releases,
releasing more often (theoretically up to 8 API breaking releases per year because 52 weeks/year divided through a 6 week branching cycle) will be a pain for business users because they have to repeat some work/testing with every release. So, is Thunderbird's new target group the mail end user or businesses which use it pretty bare?
> On 31/05/2011 10:11, Ben Bucksch wrote: >> On 26.05.2011 20:06, Mark Banner wrote: >>> We'll also be de-emphasising the version numbers in our releases, it >>> is much more important that users keep up to date with the latest >>> security and stability fixes, and of course latest improvements, than >>> being concerned that a jump from one number to the next is a big jump.
>> FYI, that *is* an important information, though. There are developers >> and companies with big deployments which need to know how much work >> they have to expect, due to API and profile file changes, UI changes >> etc.. > I think if they assess the amount of worked based on the version number > increment, then that is going to give a very poor indication of the > amount of work. For example, with the old system, what if we did a > whole-number version bump, but only actually implemented one big new > feature without changing other APIs, and without affecting their > integration. They would assume a lot of work, when in fact it would be > very little.
> Likewise, with a minor version bump, we could have changed a lot of > APIs, but not actually implemented many new features, and they would > then have a lot of work to do.
> Surely it is better to give the new release some assessment (e.g. a > quick test, brief investigation into the code), rather than rely on a > version number increment?
>> Question: Will we end up with Thunderbird 15 in a year's time (and TB >> 25 in 2 years), or what's the plan? > Yes, we'll get numbers that big.
> 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 for one think this is silly, and am not looking forward to using Thunderbird version 35, that isn't much better/different than version 3.1 was...
Come on guys... lets make changes that really matter, not just do something just because someone else did it.
The second I heard that Firefox was going down this road, I groaned inside, voicing in my head all of the negatives/downsides that have been expressed here already.
The argument that users really don't know care what version they are on is just as strong an argument *against* doing this as it is in favor of it - but the arguments against it - the above one being one of the more negatively impactful ones imnsho - are sound and numerous. _______________________________________________ tb-planning mailing list tb-plann...@mozilla.org https://mail.mozilla.org/listinfo/tb-planning
> 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.
>> Question: Will we end up with Thunderbird 15 in a year's time (and TB >> 25 in 2 years), or what's the plan? > Yes, we'll get numbers that big.
Don't you think that's ridiculous? I think that's hideous. I don't like date-base version numbers, but they're still better than "TB 25".
Marketing-wise, that's an even bigger catastrophe: It's not news to update from TB 26 to TB 27. At the moment, we get newsticker articles (e.g. on heise.de) when we make a new release. This is PR, this is free advertising. We will lose that.
> On 31.05.2011 12:06, Mark Banner wrote: >>> Question: Will we end up with Thunderbird 15 in a year's time (and >>> TB 25 in 2 years), or what's the plan? >> Yes, we'll get numbers that big.
> Don't you think that's ridiculous? I think that's hideous. I don't > like date-base version numbers, but they're still better than "TB 25".
No, I don't think that's ridiculous. What would happen if we didn't do the rapid release, didn't change the numbering system, and continued developing Thunderbird for the next 25 years? Would we reset the version number or change the product name just because the number is getting too big? I doubt it.
> Marketing-wise, that's an even bigger catastrophe: It's not news to > update from TB 26 to TB 27. At the moment, we get newsticker articles > (e.g. on heise.de) when we make a new release. This is PR, this is > free advertising. We will lose that.
Like Rafael has already said, we're not going to be marketing TB x is released. We'll be marketing that an update to Thunderbird is released. We can therefore immediately focus on the fact that we've got new features, security fixes or whatever.
I'd be pretty surprised if a news site suddenly decided not to tell its readers about a new version just because the version number got too big. The news is there's something new/different, not the fact the version number has changed.
> releasing more often (theoretically up to 8 API breaking releases per > year because 52 weeks/year divided through a 6 week branching cycle) > will be a pain for business users because they have to repeat some > work/testing with every release.
> So, is Thunderbird's new target group the mail end user or businesses > which use it pretty bare?
Just under a year ago, Dan Mosedale put a document together <https://wiki.mozilla.org/User:Dmose/Tb_Product_Notes> that aimed to help the community see where the Thunderbird product is going. In that document for the market, we stated:
"Thunderbird will focus on the individual user and Small Office / Home Office (SOHO) market segments."
I believe we haven't affected that focus with moving to rapid releases.
> didn't change the numbering system, and continued developing > Thunderbird for the next 25 years?
In the new system, we'd be at Thunderbird 221. That's not comparable with reaching "TB 25" in 2 years - in the current system, we'd be at "TB 4.0" or "5.0".
> Like Rafael has already said, we're not going to be marketing TB x is > released. We'll be marketing that an update to Thunderbird is released.
Yes, but if that happens every 6 weeks, do you think you'll get a headline each time?
If you have a release that's bigger than the others, it will be hard to communicate that "this one is significant" to reporters who get a 1000 news items a day and spend 3 seconds or less before deciding whether it's newsworthy.
> The news is there's something new/different, not the fact the version > number has changed.
From the news items I've read, few reporters go to that length. Most just report "there's a new version", and maybe reword parts of your press / public material of what's new. In the case of 26 -> 27, that whole headline of "there's a new version" is lacking. You need a reporter who actually understands the changes, and very few go to that length.
I'm not saying it's impossible to market that, but that it's *harder* in the new system to do PR and get news items. So, I'm saying that even from a marketing perspective, this is worse.
And techies also surely don't like it. So, I don't get it.
> Following several discussions, the Thunderbird drivers have decided
May I ask something? What's the purpose of this list? It's called tb-planning, which implies to me that exactly such decisions would be discussed here first and *decided* here.
Reality is, however, that this list is just *informed* about certain decisions (but not even all important developments). It therefore is degraded to a peanut gallery. _______________________________________________ tb-planning mailing list tb-plann...@mozilla.org https://mail.mozilla.org/listinfo/tb-planning
We'll be communicating with reporters the changes and features in Thunderbird and it'll be feature driven rather than using versions to drive news. We'll continue to take care of our relationship with the press and bloggers regarding new releases.
Using versioning in marketing has run its course. From a practical standpoint, Thunderbird + version number is a sub-brand that we have to market which takes away from focusing on "Thunderbird". And users care that they're using the latest Thunderbird, not Thunderbird 3.1.10.
We do need to save users from version marketing. Android, Mac OS X, Windows, Internet Explorer, Chrome, Firefox, iTunes, Ubuntu. Should I really know that I'm running Android 2.3.4 Cupcake, Gingerbread, Ice Cream Sandwich; Mac OS X 10.6.7 Lion, Snow Leopard, Hedgehog; Windows Vista, 7, 8? Ugh!
Our users don't care about version numbers, they care about using "Thunderbird" and using the latest. And I don't think we should make them care about software + version numbers.
> On 01.06.2011 23:59, Mark Banner wrote: >> didn't change the numbering system, and continued developing >> Thunderbird for the next 25 years?
> In the new system, we'd be at Thunderbird 221. That's not comparable > with reaching "TB 25" in 2 years - in the current system, we'd be at > "TB 4.0" or "5.0".
>> Like Rafael has already said, we're not going to be marketing TB x is >> released. We'll be marketing that an update to Thunderbird is released.
> Yes, but if that happens every 6 weeks, do you think you'll get a > headline each time?
> If you have a release that's bigger than the others, it will be hard > to communicate that "this one is significant" to reporters who get a > 1000 news items a day and spend 3 seconds or less before deciding > whether it's newsworthy.
>> The news is there's something new/different, not the fact the version >> number has changed.
> From the news items I've read, few reporters go to that length. Most > just report "there's a new version", and maybe reword parts of your > press / public material of what's new. In the case of 26 -> 27, that > whole headline of "there's a new version" is lacking. You need a > reporter who actually understands the changes, and very few go to that > length.
> I'm not saying it's impossible to market that, but that it's *harder* > in the new system to do PR and get news items. So, I'm saying that > even from a marketing perspective, this is worse.
> And techies also surely don't like it. So, I don't get it.
> On 26.05.2011 20:06, Mark Banner wrote: >> Following several discussions, the Thunderbird drivers have decided > May I ask something? What's the purpose of this list? It's called > tb-planning, which implies to me that exactly such decisions would be > discussed here first and *decided* here.
> Until now, we've had two primary discussion forums for driving > Thunderbird work forward. We've had dev-apps-thunderbird, which is > theoretically development-focused, but realistically has been fairly > free form, and populated by folks with an extremely wide variety of > perspectives. We've also had thunderbird-drivers, which is completely > private, and populated only by folks who are in the very center of > pushing releases out the door.
> A number of us who participate in both forums have noticed over time > that there are a non-trivial number of discussions that don't fit > very well in either place. These are things that need input from a > significantly larger group of people than the release-drivers (eg > other core developers, add-on developers, UX wizards), and they also > benefit generally from having more transparency. However, these > conversations also need to be drivable to completion without getting > derailed by emotional outpourings, venting, personal attacks, and > straw men and also without leaving the participants exhausted and > frustrated. In other words, it has to actually be _easy_ to get work > done.
> To that end, I've created a tb-planning mailing list as a middle > ground designed specifically for these sorts of discussions. I've > written up a wiki page at > <https://wiki.mozilla.org/Thunderbird/tb-planning> describing the > list mechanism and rules.
The linked document has a little more info which is, imo, worth reading.
> Reality is, however, that this list is just *informed* about certain > decisions (but not even all important developments). It therefore is > degraded to a peanut gallery.
This isn't a place where everyone gets to decide everything about Thunderbird. It's a place where some of the discussion and decisions happen. Some other things are decided by a smaller group of people, and yet other things are forced upon Thunderbird by it's place in the Mozilla world. (The new release numbering, and rapid release schedule are examples of the latter two types of things. For examples of the list discussing and deciding things, I'ld point you at the "blanket orange fixes", the "SkinkGlue", and the "statusbar removal" threads for a start.)
Reading Dan's original intentions for the list, I now slightly regret approving some of the messages in the version number thread, since, while they contained interesting viewpoints, they generally weren't helping us get work done. For that matter, the information might have originally been better expressed in a blog post. Ah well, live and learn.
Thanks, Blake. -- Blake Winton Thunderbird Front End bwin...@mozilla.com _______________________________________________ tb-planning mailing list tb-plann...@mozilla.org https://mail.mozilla.org/listinfo/tb-planning
> And users care that they're using the latest Thunderbird, not > Thunderbird 3.1.10.
Well, do they really? Since we all just assume certain user expectation, you seem to have hard data to back your claims? (And how would anybody know it's „the latest Thunderbird“ without a version number?)
> We do need to save users from version marketing.
This sentence, at least, is the real culprit: Obviously, you _do_ know that users care for version numbers, and you seem to feel that „the competition“ is better at that … (And while this may even be true for Firefox, I don't see any version number frenzy in „the mail client market“ (if there'd one at all, that is).)
> Should I really know that I'm running Android 2.3.4 Cupcake, > Gingerbread, Ice Cream Sandwich; Mac OS X 10.6.7 Lion, Snow Leopard, > Hedgehog; Windows Vista, 7, 8? Ugh!
Yes, you should, and you even do elsewhere in reality. You don't just drive „the latest GM“. And assuming that everybody will be using the latest version of a program is naive at best (especially given how many users are still using TB2, because they don't like TB3).
> Our users don't care about version numbers, they care about using > "Thunderbird" and using the latest.
Again: proof, assumption, or just wishful thinking?
> This isn't a place where everyone gets to decide everything about > Thunderbird.
I don't think anyone expects this, realistically.
But there's a difference between „we're planning X, we would like to know how you feel about, and announce our decision“ and „we decided X, and we don't care what you say“.
And there's a difference between „we decided“ and „we were forced“, of course.
> Reading Dan's original intentions for the list, I now slightly regret > approving some of the messages in the version number thread, since, > while they contained interesting viewpoints, they generally weren't > helping us get work done.
That translates to „sink or swim, you only matter if you agree“?
> Blake Winton aber hob zu reden an und schrieb: >> This isn't a place where everyone gets to decide everything about >> Thunderbird. > I don't think anyone expects this, realistically.
Well, it's sort of been treated that way for a little while. And it seems to me like it's worth re-iterating that it's not.
> But there's a difference between „we're planning X, we would like to > know how you feel about, and announce our decision“ and „we decided X, > and we don't care what you say“.
I agree, and I think we should keep the "we decided X" posts off this forum, because there isn't much useful conversation we can have about them. (On the other hand, the "we're planning X" threads I've read have been very helpful, and I would like to see more of them.)
> And there's a difference between „we decided“ and „we were forced“, of > course.
It's hard to tell which side of that difference things fall on sometimes. :)
>> Reading Dan's original intentions for the list, I now slightly regret >> approving some of the messages in the version number thread, since, >> while they contained interesting viewpoints, they generally weren't >> helping us get work done. > That translates to „sink or swim, you only matter if you agree“?
For the version number thread, I haven't seen a lot of responses which are helping us get work done. (And to be clear, I regret approving the posts which agree with the decision, too, since they don't help us move forward either.) Out of the 21 posts, I could only find a couple of constructive ones, and that's not a great ratio…
Thanks, Blake. -- Blake Winton Thunderbird Front End bwin...@mozilla.com _______________________________________________ tb-planning mailing list tb-plann...@mozilla.org https://mail.mozilla.org/listinfo/tb-planning
