Proposed Release Plan changes
mbanner at mozilla.com
Thu Aug 9 13:03:08 UTC 2012
On 09/08/2012 04:11, JoeS wrote:
> Well this has gotten me totally confused.
> from the original wiki post:
> > There are currently two editions of Thunderbird: 'Thunderbird' and
> 'Thunderbird ESR'.
>> Both will be maintained and based on the same Gecko engine release.
> Yet in the etherpad comments:
>> Thunderbird Daily builds will be kept up to date and current
>> nightly gecko
>> Keeping these running gives us:
>> continous integration with gecko updates avoiding a massive jump
>> a safe place to land patches/improvements etc for the next major
> If the first quote is correct, this means that the only way mainstream
> users will see any community driven, or Gecko core improvements is
> with a once a year release with the esr Gecko base.
Both quotes are correct. The plan is that the mainstream and ESR will be
based on the same gecko release - but remember that's Gecko in the first
statement, and we can take (via intermediate releases if there is deemed
to be enough work to warrant them) Thunderbird specific changes later
on. However, unlike previous methods of releasing, we still have a fixed
date to say when a feature will be released.
Obviously, Gecko improvements would be restricted to once a year.
Keeping Daily builds running is just the obvious thing to do - that's
where the next major release comes from, and by keeping them running it
avoids a massive amount of work in uplifting between gecko versions.
Typically, when Gecko breaks us currently (assuming it is something our
builders/test boxes pick up), we get a fairly narrow regression range
and that helps us pick up what changes we need really quickly. If we
don't keep those running, it'd be a lot harder to find all the issues,
especially because we'd likely have multiple failures.
> This separates the everyday user from the dev/testing community by a
> full year. What use is community input via bugzilla.
Yes, this would increase that separation a bit. We had it before though,
and I don't think it will cause us major pains. There may be some more
duplicate reports, but it would also be good to consider what we can do
to improve the handling of that gap. Maybe you could start a separate
thread on that?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4123 bytes
Desc: S/MIME Cryptographic Signature
More information about the tb-planning