This roadmap update takes into account the transition from using Seamonkey as our primary Gecko testbed to using Firefox and Thunderbird. Rather than shipping our Gecko 1.8 Beta 2 release as a Seamonkey milestone, we'll be shipping a Firefox and Thunderbird 1.1 testers-only preview (I'm calling that "alpha" for now). This preview for Firefox and Thunderbird will fill the release slot that was formerly occupied in the roadmap by "Mozilla [Seamonkey] 1.8 Beta 2".
For the purposes of bug tracking, the Core and Toolkit bugs targeted at this next release will use the target milestone "mozilla1.8beta2" and the blocking/approval flags containing "1.8b2". The Firefox and Thunderbird bugs will continue to use the target milestones Firefox1.1 and Thunderbird1.1 and the blocking/approval flags containing "aviary1.1"
We were scheduled to freeze for 1.8 Beta 2 on March 15th at midnight but that clearly didn't happen. There is more work, front-end and back-end (cleaning up regressions from new features, completing the heavy lifting of the Thunderbird localization re-organization, fixing key bugs, analyzing and fixing topcrashers, getting XULRunner further along, etc.) that needs to happen before we're in a position to ship the Firefox and Thunderbird 1.1 alphas.
We estimated about 10 days ago that we could get into shape for the Aviary alpha releases by extending the Mozilla 1.8 Beta 2 development period for 3 more weeks. That period of open development will come to an end on April 5 - less than a week and a half from now.
Once we freeze for the Firefox and Thunderbird 1.1 alpha releases (including the Core and Toolkit 1.8 beta 2 code) all changes landed thereafter will require drivers' approval and will be limited to the kind of changes necessary to get the 1.1 alphas shipped.
After we ship the 1.1 alphas, we still have work to be done before we're at feature complete (I'm calling that "beta" for now) for the apps, and standing up the XULRunner embedding story. The tree will stay closed after the alphas, through the betas of Firefox and Thunderbird 1.1 (and possibly a preview of XULRunner) and beyond so that we'll have some time to digest as much feedback as possible before branching.
During the beta tree closure, we'll be focused on responding to the feedback from the 1.1 alphas and fixing both core Gecko/Toolkit and XULRunner issues as well as Firefox and Thunderbird app issues. If all goes well during this period, we hope to be able to start ramping down and shoring up for the betas around May 10.
Being frozen on the trunk after beta, which is also the freeze for localizable strings, will give our L10N teams a chance to get their locales completed or nearly completed on the trunk before branching. This could save them considerable time and was an important factor in deciding to the extended trunk freeze.
Staying closed on the trunk for this long (from early April until we branch a couple months later) makes little sense if we can't all rally around the tasks that need doing for the 1.8 branch and releases (Firefox, Thunderbird, and XULRunner.) We do realize that we've got a lot of big work ahead for the 1.9 cycle and not everyone working on Mozilla is working on code directly related to the 1.8 releases so drivers solicited feedback from our active developer community about this proposal. The feedback was very support of this plan and we hope that trying something a bit new here will save us some of the pains we experienced with the last branch.
I'll be updating the Mozilla Roadmap document with dates and a branching and release graphic in the next few days.
Asa Dotzler wrote: > Rather than shipping our Gecko 1.8 Beta 2 release as a Seamonkey > milestone, we'll be shipping a Firefox and Thunderbird 1.1 testers-only > preview (I'm calling that "alpha" for now). This preview for Firefox and
Asa (and MoFo), please step back with ugly version names aka "testers-only preview" and call them normally as "alpha", "beta" and "RC". Why with every new release we should translate new names for something commonly known as alpha and beta? Why a name of version should take major part of article size? Also, why we try confuse journalists?
> Asa Dotzler wrote: >> Rather than shipping our Gecko 1.8 Beta 2 release as a Seamonkey >> milestone, we'll be shipping a Firefox and Thunderbird 1.1 >> testers-only preview (I'm calling that "alpha" for now). This preview >> for Firefox and
> Asa (and MoFo), please step back with ugly version names aka > "testers-only preview" and call them normally as "alpha", "beta" and > "RC". Why with every new release we should translate new names for > something commonly known as alpha and beta? Why a name of version should > take major part of article size? Also, why we try confuse journalists?
Did he say anywhere that this is the official naming of the product? For my perspective, it's a description of the purpose of those alpha releases.
> Rather than shipping our Gecko 1.8 Beta 2 release as a Seamonkey > milestone, we'll be shipping a Firefox and Thunderbird 1.1 testers-only > preview (I'm calling that "alpha" for now). This preview for Firefox and > Thunderbird will fill the release slot that was formerly occupied in the > roadmap by "Mozilla [Seamonkey] 1.8 Beta 2".
Just to inform people who are interested along with that, the suite release formaerly belived to be "Mozilla 1.8b2" will be released with our new suite name and a version number of "1.0a" - we'll go along and basically doing our alpha/beta/final releases of the 1.0 suite from the same Gecko/core codebase as aviary 1.1 alpha/beta/final releases.
On Mon, 28 Mar 2005 14:26:34 +0200, Robert Kaiser wrote: > Just to inform people who are interested along with that, the suite > release formaerly belived to be "Mozilla 1.8b2" will be released with > our new suite name and a version number of "1.0a" - we'll go along and > basically doing our alpha/beta/final releases of the 1.0 suite from the > same Gecko/core codebase as aviary 1.1 alpha/beta/final releases.
Will Wossname 1.0a have the same GUID as Mozilla Suite 1.x?
Phil
-- Philip Chee <phi...@aleytys.pc.my> Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. [ ]Xerox never comes up with anything original ... * TagZilla 0.057
On 2005-03-28, Asa Dotzler <a...@mozilla.org> wrote: [snip]
> We were scheduled to freeze for 1.8 Beta 2 on March 15th at midnight but that clearly > didn't happen. There is more work, front-end and back-end (cleaning up regressions from > new features, completing the heavy lifting of the Thunderbird localization > re-organization, fixing key bugs, analyzing and fixing topcrashers, getting XULRunner > further along, etc.) that needs to happen before we're in a position to ship the Firefox > and Thunderbird 1.1 alphas.
Does that "etc" include working on new features...?
> After we ship the 1.1 alphas, we still have work to be done before we're at feature > complete (I'm calling that "beta" for now) for the apps, and standing up the XULRunner > embedding story. The tree will stay closed after the alphas, through the betas of Firefox > and Thunderbird 1.1 (and possibly a preview of XULRunner) and beyond so that we'll have > some time to digest as much feedback as possible before branching.
I could be wrong, but AIUI, the timescale was extended because there wasn't time to complete the original work plan. Now that the timescale has been extended, there seem to be plans to do a bunch of extra stuff. Unless a bunch of extra coders have suddenly turned up or I've missed something, that either means that the original schedule did not need to be extended, or it means that the new schedule is once again unrealistic, and we'll be looking at betas in June/July, and aviary 1.1 in August/September.
If the alphas aren't feature complete, then there will be little difference between the pre-alpha phase and the pre-beta phase, and the bug fixing and stabilisation work basically won't start until after the betas.
> Staying closed on the trunk for this long (from early April until we branch a couple > months later) makes little sense if we can't all rally around the tasks that need doing > for the 1.8 branch and releases (Firefox, Thunderbird, and XULRunner.) We do realize that > we've got a lot of big work ahead for the 1.9 cycle and not everyone working on Mozilla is > working on code directly related to the 1.8 releases so drivers solicited feedback from > our active developer community about this proposal.
Which drivers are you talking about here? AIUI, there was previously a set of drivers for Seamonkey/Core stuff (those listed at http://www.mozilla.org/about/drivers ), and then a couple of people playing the drivers role for the aviary front-end bits - has that changed?
If there's going to be feature work and heavy lifting happening anyway, why not just leave the trunk open until the betas happen?
This GUID is included in install.rdf of extensions that support Mozilla Suite, with min/maxVersion around 1.7 (I don't have exact information), per UMO request. So you can't say it's not used.
Will UMO have extensions for the new community project, and if so, will it still have extensions for Mozilla Suite?
> This GUID is included in install.rdf of extensions that support Mozilla > Suite, with min/maxVersion around 1.7 (I don't have exact information), > per UMO request. So you can't say it's not used.
Hmm, tur, I didn't think of UMO using that combination of GUID and minVersion/maxVersion, internally in the suite code, the GUID is still dead meat actually... But UMO might be a reason for assigning a new GUID, true...
> Will UMO have extensions for the new community project, and if so, will > it still have extensions for Mozilla Suite?
> This GUID is included in install.rdf of extensions that support Mozilla > Suite, with min/maxVersion around 1.7 (I don't have exact information), > per UMO request. So you can't say it's not used.
BTW, where is UMO taking the version info from? The UA? Somehwere else? If we change the GUID, it would be good to make them use our correct version number with it...
-- Philip Chee <phi...@aleytys.pc.my> Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. [ ]ACRONYM: Abbreviated Coded Rendition Of Name Yielding Meaning * TagZilla 0.057
On Tue, 29 Mar 2005 14:36:31 +0200, Robert Kaiser wrote: > Nickolay Ponomarev schrieb: >> This GUID is included in install.rdf of extensions that support Mozilla >> Suite, with min/maxVersion around 1.7 (I don't have exact information), >> per UMO request. So you can't say it's not used. > Hmm, tur, I didn't think of UMO using that combination of GUID and > minVersion/maxVersion, internally in the suite code, the GUID is still > dead meat actually... > But UMO might be a reason for assigning a new GUID, true...
One way around this is to have the "external" numbering different from the "internal" version. e.g. Solaris 10 ~= SunOS 5.10. Internally - uname will return 5.10 but the visible GUI eye-candy says Solaris 10.
This method allows extension developers to have one less GUID/compatibility/ version to keep track of.
Phil
-- Philip Chee <phi...@aleytys.pc.my> Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. [ ]USER ERROR: Please replace user and hit enter to continue * TagZilla 0.057
Philip Chee wrote: > On Tue, 29 Mar 2005 14:36:31 +0200, Robert Kaiser wrote:
>>Nickolay Ponomarev schrieb:
> One way around this is to have the "external" numbering different from the > "internal" version. e.g. Solaris 10 ~= SunOS 5.10. Internally - uname will > return 5.10 but the visible GUI eye-candy says Solaris 10.
> This method allows extension developers to have one less GUID/compatibility/ > version to keep track of.
> Phil
This would require some changes to UMO I think, I am not [in the least] up on their codeing practices.
However internally in "Mozilla Suite" there is no Extension code which uses any GUID (since Suite does not use the Extension Manager...yet)
There does seem reason to assign the "Project" a new uuid to me, for both UMO's sake and ours for when our version gets close to 1.7 ...
Also an internal/external version will confuse people, especially the very people who would develop extensions for this program, Hmm I have Foo 1.1 but its version is 1.9 ... odd what do I enter in min/max version...
...Especially if the exact same extension works for "Mozilla Suite 1.7" and "Project Suite 1.0" as an example, it does seem a bit odd to label it seperately like that.
Yes this will slow acceptance into UMO (if UMO architetchure is provided for us) and will slow fast adoption of a new uuid, but from where I sit it may be a much better solution in the long run.
In our contexts GUID is used in the file "install.rdf" for Extension Manager's sake when a developer creates an extension for Firefox/Thunderbird/et-all they provide a pre-generated GUID which designates the application they (the developer) claims to support with their extension. UMO uses that GUID to "understand" which Applications the extension supports, which is why Suite has a GUID even though the source code in it does not actually use the GUID (Firefox and TB do read the GUID)
These extension authors also generate a GUID (via any means) for their own extension, to have an identifier that is unique for their extension itself.
Lastly you can even generate a UUID by messageing any MozBot (IRC Bot), [such as botbot on moznet (irc.mozilla.org)], |/msg botbot uuid| and it will reply with a new GUID for you.
The algorithim to generate these is near-guaranteed to be unique (there is always a chance for conflict, but for our uses the chance is slim to none).
