Re: next emacs version?

[Ken Raeburn <raeburn@raeburn.org>]

On Mar 19, 2010, at 23:38, Drew Adams wrote:
>> 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.

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.

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

Or anyone redistributing emacs in a software distribution, maintaining a local installation for a site, etc.  Thinking back to the gcc-2.96 mess, where there was no official release with that number, but lots of people wound up running something identifying itself that way anyways.

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

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

Ken