This thread's been dormant for a bit, so I'm afraid to disturb it :-).
However, eventually someone's going to file it as a 1.0 candidate
change (probably after they have a patch ready), or move issue #408 to
be a 1.0 candidate.
So, this is an anticipatory post explaining why I hope we do *not*
tackle this problem for 1.0.
Reason 1: As much as we dislike our current date parser, it hasn't
caused us many actual problems. It's not like we had a
bunch of defects filed about date parsing, and then realized
that we couldn't release 1.0 without fixing them. We have
issue #408, sure, but that's "date parser rewrite", so it
would be circular to view it as a justification in itself :-).
Reason 2: Unlike some of the simple API fixes and whatnot we've been
bandying about, this actually has the potential to cause
bugs. It'd need a lot of review, and even then it's still
possible for there to be subtle misparsings that don't get
found until after 1.0.
Reason 2: There are post-1.0 compatibility strategies that make this
change less compelling. For one thing, any new parser we
write is going to intersect with some of what the current
parser supports. We can then look at current side of the
non-intersecting area and see how important some of those
formats really are. It's not outside the bounds of
propriety to break dates used by ~20 people in the world (if
we can determine that with reasonable certainty).
But even if we don't want to lose *any* compatibility,
there's still a strategy available. The current date parser
is not known to misparse anything (right?) -- it simply
doesn't parse everything we want it to, and is hard to
maintain. If we write a new parser, it certainly wouldn't
differently parse any string that is correctly parsed by the
old code. So, we can just pass input to the old code first,
then if it fails, we try the new code. That way we don't
have to "maintain" the old code, so much as preserve it in
stasis until the new code matches it in sophistication -- a
process that can take as long as we're comfortable with,
since there's no great penalty to keeping the old code
around.
For these reasons, I think it is unnecessary (and even a bit risky) to
futz with our date parser before 1.0. Let's leave well enough alone.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 19 22:34:21 2003