Fwd: TB Summary of release discussion
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning