RE: next emacs version?

[Drew Adams]

> > OK in this particular case, but the general question 
> > remains. If this change had been made in a 23.0.50.1 dev version
> > (or whatever the nomenclature is), then some such dev versions
> > would have the change and some would not.
> 
> Unless you want to start putting bzr revision numbers into 
> the emacs version string (which I think is a bad idea), 

Agreed; a bad idea.

> that's going to be the case.  Version numbers like 23.0.50.1 
> apply to a long string of development revisions.

Yes, that was my understanding.

> 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.

> If you (=> users of your, Drew's, code) want to experiment with 
> development versions, it shouldn't be too much to ask for you 
> to keep fairly current, or at least update before complaining 
> about bugs.

It's not about bugs or keeping current. The user in question ("you") had the
very latest BZR code in his build.

The point is that whereas it is typically simple to support fine-grained
differences when a change adds a variable or function (use boundp or fboundp),
other kinds of changes are not so easily identified.

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).

> (And if you want to ship non-released development versions to
> your friends or customers, you're on your own.)

I guess "you" here is back to meaning me, rather than users of my code. No, I
don't ship Emacs versions of any kind.

And I generally don't try to support Emacs development versions in my libraries.
Instead, I wait until the next release to update my code.

But sometimes (esp. if the release cycle is long) I do make changes (esp. if
minor) that allow my code to keep working with the latest development version.
That's sometimes easy when it concerns a new var or fn (but not arity change
etc. for a fn). Otherwise, it is usually impractical.

A case in point: changes to info.el immediately after the 23.1 release. I did
update my code to accommodate those changes, to allow users to keep using my
code. Otherwise, their only choice is to either forego using my library until
the next release or forego using the latest (dev) Emacs.

But in general trying to keep up with Emacs dev changes is something I avoid,
even if users would prefer to keep up-to-date with Emacs dev and still have
their 3rd-party code also work.

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".