RE: next emacs version?

[Stephen J. Turnbull]

Drew Adams writes:

 > > If you need discrete points in time where you can distinguish "fixed 
 > > before" from "fixed after", that's what releases are for.
 > 
 > The granularity is too gross.

Too bad.  There's no good way to linearize the whole DAG for your
purpose.  Dates won't work because parallel branches will not
necessarily merge a given change at the same time.  The approximation
used is for the Emacs developers to agree on a conventional ordering,
which is called "the mainline".  If you know your user is "on the
mainline", then dates can be used to do the ordering, or the revision
number.  The problem with the revision number, though, is that in
general it is unstable (the same revision will be numbered differently
in different workspaces, depending on which branch they are derived
from).  Note that pragmatically the reason for using releases as
markers is that socially the project (except for a very few long-lived
branches, and the special "pending" branch, which may be used by users
who should be assumed to know what they're doing) converges to a
*single* point of agreement.  After a release, things get fuzzy.

And if your users are using the pending branch, or a feature branch
(such as Eli's bidi or Miles's lexbind), all bets are off.  You really
should just tell those folks it's *their* problem.  After all, that's
what they asked for by using bleeding edge branches.

 > In practice, many large changes do involve some change that is
 > readily identifiable (e.g a new fn). In the case in point, the code
 > change was small (a new regexp value) but the change in effect was
 > not so small (use of the regexp for font-locking).

Grin and bear it, man.  On this one, you lose.  You are not going to
get the fine-grained test you want.  The exact form of that test is to
trace back in bzr's DAG for the build to determine whether the
revision that introduced the change is an ancestor of this build.
(And even that's not good enough, because it might get reverted or
"perverted" by a later change that you'd have to test for.)

For your purpose here, you can test the regexp value (or even force it
to one you can deal with).  Or you can test for release order and tell
users that "between these two releases you're out of luck."

 > This is a common occurrence/predicament. I (and I assume others
 > too) sometimes get bug reports for my libraries that really amount
 > to Emacs dev changes "breaking" things. Much of the time my answer
 > must be "Too bad. I don't support ongoing Emacs development. Wait
 > until the next Emacs release".

What's the problem?  That is the correct answer (modulo the addition
of "patches that work before and after the Emacs change welcome", if
appropriate for your development policy).