Fwd: TB Summary of release discussion

Unicorn.Consulting unicorn.consulting at gmail.com
Wed Sep 19 23:10:45 UTC 2012


On 20/09/2012 12:29 AM, Kent James wrote:
>
> 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?
I have no real objection.

>
> :rkent
>
>
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning


-- 
  "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." Benjamin Franklin

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


More information about the tb-planning mailing list