176897 - fork rules.dat

Status: VERIFIED DUPLICATE of bug 168553

(MailNews Core :: Filters, defect)

Description

[(not reading, please use [e-mail] instead)]

fork rules.dat.

there might be a bug for this.

before we flip the switch and fork, we need to make sure we've finished all the
planned backend changes that require a fork. (mscott's views, new filter
actions, new filter criteria, junk mail, etc)

more coming soon.

I'll make sure this bug is blocked by all the right bugs.

Comment 1

[David :Bienvenu]

I think we need a plan for this. I guess Scott has already checked his stuff in,
though not turned on in Mozilla, so maybe the horse is out of the barn already.
But, it seems to me that what should happen is that we should turn on all the
changes that require a fork at the same time that we check in the code that does
the fork. If we check in code that will change the format of the filters file
w/o checking in the forking code, we might break the ability to go back and
forth between 7.0 and the tip of the trunk bits. And if we break people's
filters, we will make a lot of people unhappy. It's one thing for an old version
of mozilla to be unable to read a newer filter format, but another for it it to
read the newer filter format, but lose information when it writes it back out.
One simple approach going forward would be to change the filing code to read
newer format filter files, but refuse to write out the file, on the theory that
it might not have read the filter file correctly.

I realize this sounds like an enormous pain since everything would need to be
turned on at once, and some of the work hasn't started yet. In theory, we could
do just the filing code for the features that aren't done yet (I'm thinking of
the new filter actions, forward and reply), but I'm not sure exactly what file
format wil be for the data of these actions. I guess would could just say it's a
string and leave it at that.

Comment 2

[Navin Gupta]

I think mscott didn't checkin filter related part. He just checked in views part
that is persisted in mailViews.dat or something. 

I already have a patch for this.

*** This bug has been marked as a duplicate of 168553 ***

Comment 3

[(not reading, please use [e-mail] instead)]

I'll take david's comments and some comments from mscott to the existing bug.

Comment 4

[laurel]

marking verified as a duplicate