[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: next emacs version?
From: |
Ken Raeburn |
Subject: |
Re: next emacs version? |
Date: |
Sat, 20 Mar 2010 01:31:28 -0400 |
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
- RE: next emacs version?, (continued)
- RE: next emacs version?, Drew Adams, 2010/03/19
- Re: next emacs version?, Eli Zaretskii, 2010/03/19
- RE: next emacs version?, Drew Adams, 2010/03/19
- Re: next emacs version?, Ken Raeburn, 2010/03/19
- Re: next emacs version?, Lennart Borgman, 2010/03/19
- Re: next emacs version?, Óscar Fuentes, 2010/03/19
- Re: next emacs version?, Lennart Borgman, 2010/03/20
- Re: next emacs version?, Ken Raeburn, 2010/03/20
- Re: next emacs version?, Stephen J. Turnbull, 2010/03/22
- RE: next emacs version?, Drew Adams, 2010/03/19
- Re: next emacs version?,
Ken Raeburn <=
- RE: next emacs version?, Drew Adams, 2010/03/20
- Re: next emacs version?, Ken Raeburn, 2010/03/20
- RE: next emacs version?, Drew Adams, 2010/03/20
- RE: next emacs version?, Stephen J. Turnbull, 2010/03/22
- Re: next emacs version?, Miles Bader, 2010/03/23
- RE: next emacs version?, Drew Adams, 2010/03/23
- Re: next emacs version?, Jason Rumney, 2010/03/19
- RE: next emacs version?, Drew Adams, 2010/03/20
- Re: next emacs version?, Eli Zaretskii, 2010/03/20
- RE: next emacs version?, Drew Adams, 2010/03/20