Fwd: TB Summary of release discussion

Kent James kent at caspia.com
Wed Sep 19 14:59:00 UTC 2012


On 9/19/2012 1:31 AM, Mark Banner wrote:
> On 18/09/2012 17:03, Kent James wrote:
>>
>> I think that the concern that Matt and I are showing is that each new 
>> *. release seems to come with a few new critical issues that are not 
>> resolved until the *.0.1 or *.0.2 release. Currently ESR 17 is the 
>> same as TB17 and has the same initial instability.
>>
>> Why is that needed? Why not delay the ESR release relative to the 
>> main release until some period of time has elapsed for those 
>> instabilities to get worked out? ESR has no rush to it.
> I can understand the concern, but I don't believe it is really 
> critical to ESR. Despite our mentions about testing the changes, I'm 
> pretty sure some organizations won't start widely testing until the 
> next ESR is actually released. So if there are issues that affect them 
> specifically, they may not get reported until we release the ESR. If 
> we delayed releasing that ESR for a couple of point releases, then 
> they would be in the case where the old ESR version would be 
> unsupported, but they might not be able to upgrade to the new version 
> due to the issues.
>
> The overlap is there for exactly this reason - upgrade straight away 
> if you can, but if not, you've got 12 weeks to resolve any issues (or 
> get us to resolve them).
That's a good point. I had not thought of the issues of the overlap.
>
>> The problem we are trying to solve is preventing the *.0.0 
>> instabilities from hitting the ESR channel, so that ESR users do not 
>> have to go through a period of pain before the release stabilizes. 
>> Matt's proposal does this better than my initial proposal.
> Something else to point out here I think, is that when we release ESR 
> 17.0, only syadmins that choose to upgrade their uses to the new ESR 
> version will do so. As there will be two more ESR 10.0 releases (one 
> in sync with ESR 17, the second in sync with 17.0.1), I don't see us 
> prompting 10.0 users to do a major upgrade until 17.0.2 is released 
> and 10.0.x is obsolete.
OK that's news to me, thanks for pointing that out.

With this discussion,  I think that I am going back to my earlier 
position, that the best way to use an intermediate release would be to 
release a Thunderbird 23 or 22, so that we would get some additional 
user feedback on issues before we get locked in for another year.

What do you think, Matt?

:rkent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20120919/0e5ffe09/attachment.html>


More information about the tb-planning mailing list