Closed Bug 70753 Opened 22 years ago Closed 21 years ago
.0] Tracking bug for XUL 1 .0 changes
Target Milestone: --- → mozilla1.0
For those following this bug, no XUL syntax changes that result in incompatible syntax will be allowed to land before the 0.8.1 freeze. If you do produce patches, hang on to them until then. We need to wait for the new mailnews front end to come in from the branch before we check in any of these changes.
Two things: Based on the coordination issues encountered with 70747 and 70746 (documented mostly in bug 70746), I'd suggest some guidelines be set for coordinating with commercial for XUL syntax landings. Maybe once a XUL syntax change gets an r and sr we can give commercial folks n number of days to catch up before landing? Also, what about external users that will be impacted? Should npm.xpfe be considered a wide enough distribution for warnings when these changes are imminent? I'm not sure 1.0 is the right target if the recommended vendor branch milestone is still 0.9. Mozilla's XUL is already incompatible with Netscape's 6.0x releases, it would be a real bummer to have several sets of incompatibilities between 6.0x, whatever branches from 0.9, and mozilla 1.0... Thoughts?
maolson: commercial can't mean just netscape.com's commercial build. There are lots of organizations, for-profit commercial or not, who depend on XUL standards set by trunk cvs.mozilla.org code changes. Coordinating all of these is hard, and will slow down XUL evolution something fierce. OTOH, the larger "XUL community" can't take much more incompatible change, IMO. e.g., chatzilla now must fork to support Netscape 6/mozilla0. and the new label-based mozilla0.9. Anyway, blake's changes were circling for weeks, as I understand it. What value of n (for n days) did you have in mind? I think vendors can base betas on 0.9 provided we don't make *significant* incompatible changes after this and before 1.0. Maybe hyatt can prognosticate on the likelihood of such. Small changes are tricky; I'm not sure how to define significant. In my experience with JS, some changes are too obscure to affect enough people to prevent the change from being made ASAP. /be
I totally agree with Maolson's suggestion. "n" can be a matter of 1 day in the least. It is just giving us a heads up when the landing is happening. In the 70736, 70737 case, Blake and Mao still coordinated it with us on the day of landing. Otherwise, AIM would have been in a really bad shape today. Either posting to xpfe the plan to landing or sending a mail to seamonkey-internal will be greatly appreaciated. It just doesnt make sense to just catch up with the landings after it is done and just making the changes without testing. (Although in this particular case, we did just that and things worked so nicely. Cant expect every change to be so well implemented though!) Just my two cents. Thanks!
Nominating for mozilla 0.9. I think this stuff should be in in time for the .9 milestone, so we can have time to catch problems between .9 and 1.0. Checking in major syntax changes after .9 seems to me to be a bad idea, as .9 to 1.0 should be a ramp-down time, and a time to find any problems caused by the changes. As far as the Commercial vs. mozilla issue, I think we were a bit behind on what was going on with this, and will make the effort to keep up. If mao, blake, and others could give us even a day to test the changes, and get up to speed on each landing, it would be greatly appriciated. I know this is not required, nor should it be, but it would be very much appriciated. I want to thank blake and mao again, in public, for their help with getting AIM and the rest of commercial up to speed. Without it, we would not even have comm. builds to test the changes on today.
Summary: [XUL Syntax] Tracking bug for XUL syntax changes → [XUL Syntax] Tracking bug for XUL changes
Summary: [XUL Syntax] Tracking bug for XUL changes → [XUL1.0] Tracking bug for XUL 1.0 changes
Please keep in mind that one of these XUL thingies is keeping the Themes on x.themes.org from installing (working):( For that reason alone, I suggest: nsCatFood and mozilla0.9.1
OS: other → All
Hardware: PC → All
cc self, Added as blocker of MachV schedule tracking bug (102472), added meta keyword, set Priority P2. Need to finish spec, flesh out remaining tasks, get r= for spec and plan.
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
don't move bugs that are in the 1.0 dependency tree. sorry.
Target Milestone: mozilla1.0.1 → mozilla1.0
21 years ago
No longer depends on: 93181
Please update this bug with an [adt1] - [adt3] impact rating (or take it off the list if it doesn't even rate adt3.) Thanks!
-> move tracking bug to mozilla1.0.1 to get it off radar (although me personally is having difficulty in keeping the variety of keywords, radars, and other tracking systems straight. At one point, a 'meta' keyword would keep this off some queries, but anyways...).
Target Milestone: mozilla1.0 → mozilla1.0.1
What about bug 132831? Suitable for nominating here?
Seems like this tracking bug is now fixed. All of its dependencies are fixed (except for one bug, but that's not a API change and was mis-added to this bug, AFAIK). Any objections to marking it FIXED?
Tracking bugs don't fit the definition of 'fixed'. resolving as wfm.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.