Closed Bug 70753 Opened 22 years ago Closed 21 years ago

[XUL1.0] Tracking bug for XUL 1.0 changes


(Core :: XUL, defect, P2)






(Reporter: hyatt, Assigned: hyatt)




(Keywords: meta, Whiteboard: [XUL1.0] Need to finish spec & plan, get reviews)

Blocks: 70704
Blocks: 70745
Blocks: 70746
Blocks: 70747
Blocks: 70748
Blocks: 70750
Blocks: 70751
No longer blocks: 70704, 70745, 70746, 70747, 70748, 70750, 70751
Depends on: 70704, 70745, 70746, 70747, 70748, 70750, 70751
Whiteboard: [XUL1.0]
Target Milestone: --- → mozilla1.0
Depends on: 70809
Depends on: 70810
Depends on: 70857
Depends on: 70858
Depends on: 70860
Depends on: 70877
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.
Blocks: 70974
No longer blocks: 70974
Depends on: 70974
Depends on: 71106
Depends on: 71470
Depends on: 71471
Depends on: 72923
Blocks: 24689
No longer depends on: 71470
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's commercial build.  There are
lots of organizations, for-profit commercial or not, who depend on XUL standards
set by trunk 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.[678] 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.

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.
Keywords: mozilla0.9
Depends on: 73325
Depends on: 73669
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
Depends on: 73671
Depends on: 74188
Depends on: 75143
Depends on: 76800
Please keep in mind that one of these XUL thingies is keeping the Themes on from installing (working):(

For that reason alone, I suggest: nsCatFood and mozilla0.9.1
Depends on: 93171
Depends on: 93172
Depends on: 93175
Depends on: 93177
Depends on: 89998
Depends on: 90001
Depends on: 93180
Depends on: 93181
Depends on: 93519
Depends on: 93626
No longer depends on: 93626
Depends on: 93836
No longer depends on: 70974
Depends on: 93839
Depends on: 94942
Depends on: 94943
Depends on: 94944
Depends on: 95005
Depends on: 95022
Depends on: 94255
Depends on: 95337
Depends on: 94470
Depends on: 95876
Depends on: 96008
Depends on: 96019
No longer depends on: 73669
OS: other → All
Hardware: PC → All
Depends on: 96173
Keywords: mozilla0.9
Depends on: 96179
Depends on: 12164
Depends on: 96273
Depends on: 91041
Depends on: 97062
No longer depends on: 93175
Depends on: 96812
Depends on: 97571
Depends on: 97574
Depends on: 99876
No longer depends on: 95022
Depends on: 7639
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.
Blocks: 102472
Keywords: meta
Priority: -- → P2
Whiteboard: [XUL1.0] → [XUL1.0] Need to finish spec & plan, get reviews
Depends on: 103723
Depends on: 83842
Depends on: 108303
Depends on: 110155
Depends on: 110156
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 
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
Depends on: 113696
Depends on: 118683
Depends on: 119067
Depends on: 119297
Depends on: 119298
Depends on: 119676
Depends on: 118038
Depends on: 119301, 121545
Depends on: 52140
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?
Depends on: 132831
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,

Any objections to marking it FIXED?
Tracking bugs don't fit the definition of 'fixed'.  resolving as wfm.
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.