RE: next emacs version?

["Drew Adams" <drew.adams@oracle.com>]

> If you insist that they keep current (or more specifically, 
> that the only dev version you'll support is the current one, 
> when you support any dev version at all), you shouldn't need 
> anything more fine-grained than "release X" or "dev version 
> leading up to release Y", should you?  I think I'm confused 
> about whether you're trying to support people running 
> outdated dev versions.

Yes, I wasn't very clear.

My only real intention is to support official releases. Occasionally, I try to
support the latest dev version (or the dev version when I make the update) as
well as the last (i.e., previous) release.

The point of fixing things so the code still works after the last release is so
that users can continue to use it. But Jason is no doubt right that most people
who use dev versions rebuild frequently. 

> > 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.
> 
> When you do this, do you also try to keep it working with the 
> earlier development versions?  Or is it okay to break things 
> for dev-from-last-month as long as 23.1 and 
> dev-from-this-month both still work?

The latter is fine, from my point of view.

> If the changes are easy enough to identify, supporting all of 
> them is great.  But if they're too difficult to identify 
> without resorting to version numbers, is it really that 
> important to support (in effect) multiple dev versions rather 
> than just the latest (at this point, perhaps along both of 
> the next-minor-release and next-major-release branches)?

No, I have no intention of supporting multiple dev versions in different ways.