sort out enum nsDOMClassInfoID frozenness

RESOLVED FIXED

Status

()

Core
DOM
RESOLVED FIXED
12 years ago
3 months ago

People

(Reporter: dbaron, Unassigned)

Tracking

1.8 Branch
Points:
---
Bug Flags:
blocking1.9 -
wanted1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
The frozenness of the enum values in enum nsDOMClassInfoID is sort of a mess.  A whole bunch changed between 1.7 and 1.8 because stuff got added in the middle.  And the branch landings for 1.8.1 are creating a bit of a mess; things are ending up in a different order on branch and trunk.

If we want this to be frozen (for whom?  It's frozen, but why do we care?), we need to have big comments that say:

/******** IDs above this line are frozen as of Mozilla 1.8 ********/

/******** IDs above this line are frozen as of Mozilla 1.8.1 ********/

etc.  And there might have been some insertion-in-the-middle between 1.8 and 1.8.1, which we should fix before 1.8.1 ships.

(It might also be nice to get rid of the on-by-default ifdefs above those lines, but that's another issue.  Sort of.)
(Reporter)

Updated

12 years ago
Flags: blocking1.9a1?
Flags: blocking1.8.1?

Updated

12 years ago
Flags: blocking1.8.1? → blocking1.8.1+
(Reporter)

Comment 1

12 years ago
I talked to jst about this on Friday and he thought we should give up on the idea that these IDs are frozen.
(Reporter)

Comment 2

12 years ago
Clearing blocking1.8.1 on that basis.
Flags: blocking1.8.1+
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [wanted-1.9]
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Assignee: general → nobody
QA Contact: ian → general
nsDOMClassInfoID is gone as of bug 1442039, so I claim this is sorted out.
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.