Closed Bug 514398 Opened 10 years ago Closed 10 years ago
IMsg Folder Listener and ns IMsg Folder Notification Service were modified without changing iid
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729) XPCOMViewer/0.9a Build Identifier: Take a look at diff in mercurial http://hg.mozilla.org/comm-central/diff/59db95131052/mailnews/base/public/nsIMsgFolderListener.idl http://hg.mozilla.org/comm-central/diff/59db95131052/mailnews/base/public/nsIMsgFolderNotificationService.idl Reproducible: Always
That change was done back in Dec 2008 (iirc somewhere between beta 1 & beta 2). The iids have been changed since Thunderbird 2. Whilst I agree that a change like that should have the iid bumped, I see no reason in this case to post-change that iid as any extension wanting to support Thunderbird 2 and Thunderbird 3 can easily do so as the iid was changed between the major versions.
(you are welcome to provide a counter-argument if you wish, I just don't see the point at the moment).
This is exactly what happened to me. I do a binary extension that supports Tb2 & TB3. It had a working with TB3B1 and now I tried it with TB3b3 and I was really surprised that was called different method (I found that there were added methods into middle of interface). Btw what happens if I specify in install.rdf support for Tb2 & TB3 <em:minVersion>2.0</em:minVersion> <em:maxVersion>3.*</em:maxVersion> and user will have TB3B1? Will be extension loaded into TB3B1? Or it works just for an official releases?
Btw. Is there any issue with changing iid? My opinion is that for binary extension is much simpler to find out crash immediately after QueryInterface return NULL then do a debugging and later find out that interface was changed.
(In reply to comment #4) > Btw what happens if I specify in install.rdf support for Tb2 & TB3 > > <em:minVersion>2.0</em:minVersion> > <em:maxVersion>3.*</em:maxVersion> > > and user will have TB3B1? > Will be extension loaded into TB3B1? > Or it works just for an official releases? It will be allowed in any version between 2 and 3.* (note, 3.* will be 3.1, 3.2 as well as 3.0). So you have a good point. Whatever we do, the extension will be broken for Beta 2 & beta 3 builds (or beta 1 & earlier) as we don't allow multiple ranges on extension versions, but it is probably just best to take the iid change I guess. (In reply to comment #5) > Btw. > Is there any issue with changing iid? > My opinion is that for binary extension is much simpler to find out crash > immediately after QueryInterface return NULL then do a debugging and later find > out that interface was changed. Well generally I like changes to have a reason for them - changing a iid that someone forgot about 9 months after it happened didn't seem to fall into that category. I'd forgotten about the single range version issue which is really what causes the problem here. If there wasn't a single range, then I'd have said you could have scoped your extension to 2.0* and 3.0 beta 2 to 3.0*.
Comment on attachment 398359 [details] [diff] [review] New iids for modified interfaces Checked in: http://hg.mozilla.org/comm-central/rev/71b3937a084c
Assignee: nobody → pjemen
Status: NEW → RESOLVED
Closed: 10 years ago
Component: General → Backend
Product: Thunderbird → MailNews Core
QA Contact: general → backend
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.0b4
Version: unspecified → Trunk
You need to log in before you can comment on or make changes to this bug.