unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Bastien'" <bastienguerry@googlemail.com>,
	"'Xavier Maillard'" <xma@gnu.org>
Cc: emacs-devel@gnu.org
Subject: RE: Readings for an emacs package maintainer ?
Date: Mon, 1 Jun 2009 10:05:37 -0700	[thread overview]
Message-ID: <6549BA1A13BD451180069A977B7E6685@us.oracle.com> (raw)
In-Reply-To: <87ws7worgg.fsf@gnu.org>

> > What do you, emacs developers, do in order to have the larger
> > backward compatibility spectrum ?
> 
> I'm under the impression that most developers only worry 
> about backward compatibility when users complain.  Which is
> a fairly wise way of being lazy, no?

Sure, unless you also want to help potential users who might not complain.

It really depends what you're trying to do. I tend to make things work in older
releases when the thing I'm creating is possible (reasonable to implement) in
the older releases also. I don't bother, if it's unreasonable. If something
depends on Unicode support, for instance, then Emacs 23 is a must.

Most of the time, the coding difference is not great, however, so it's no big
deal to also make stuff available to users of old releases. 

It does mean testing in the older releases, so that you will realize it if
function `blah' is not available in an older version and must be worked around.
I implement using Emacs 20 some of the time, then test in recent releases. That
typically means fewer gotchas (functions and features that don't exist) than the
other way around.

Q. Why bother? A. Why do you write your code in the first place? If it's for use
by others in addition to yourself, then why not help more of them use it?

There are *lots* of people who use Emacs versions installed by their IT
department, sometimes on hosts where they cannot install alternative code (at
least not for widespread use). And those IT-installed versions are often quite
old (Emacs 21 at Oracle, for example). 

Two reasons: (1) IT doesn't care whether users have the latest and greatest, and
more frequent updates means more work. (2) IT thinks older means more stable,
which means less work. Unicode will likely be an exception, at least in some
countries, but most new Emacs features are not things that will make IT
departments rush to scoop up the latest. 

I would guess that 99% of the developers at Oracle use Emacs 21 (or vi), simply
because that's what's there. In most cases, they could build Emacs on their
machines, for their own use or shared use by colleagues, but (I assume) they
don't care enough to do that.

There are many actual and potential Emacs users who do not necessarily want to
build Emacs themselves (1+). They use what's already available, and that is
often *not* the latest and greatest.

If you are interested in helping such users take advantage of your code, then
typically the effort needed is no big deal. You will need (and will develop, if
you do this) some awareness of which releases introduce which new functions,
macros, and variables - and change which signatures or behaviors. That's not a
bad thing to be aware of, in any case.

I would _guess_ that the fact that *lots* of Emacs users use older releases is
something underrecognized or underrepresented in the Emacs mailing lists and Web
sites. What proportion? Dunno. Maybe it's the majority - I really have no idea.
Does anyone on emacs-devel have a good idea of the proportion who use something
before Emacs 22? Is it 10%? 80%? Is there a breakdown somewhere of existing
users and their releases?

If Emacs had a Support department or were receiving regular maintenance revenue
from users of old releases, we would have such an idea. ;-)






  reply	other threads:[~2009-06-01 17:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-01  7:18 Readings for an emacs package maintainer ? Xavier Maillard
2009-06-01  9:13 ` Lennart Borgman
2009-06-01 16:14   ` Drew Adams
2009-06-01 18:56     ` Reiner Steib
2009-06-01 19:04       ` Lennart Borgman
2009-06-01 19:11       ` Drew Adams
2009-06-01 12:43 ` Xavier MAILLARD
2009-06-01 14:15   ` Miles Bader
2009-06-02  2:17     ` Stephen J. Turnbull
2009-06-02  2:36       ` Miles Bader
2009-06-02 12:02       ` Deniz Dogan
2009-06-02 14:07         ` Stephen J. Turnbull
2009-06-01 16:15   ` Drew Adams
2009-06-01 16:21 ` Bastien
2009-06-01 17:05   ` Drew Adams [this message]
2009-06-01 20:35 ` Stefan Monnier
2009-06-01 22:01   ` Leo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6549BA1A13BD451180069A977B7E6685@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=bastienguerry@googlemail.com \
    --cc=emacs-devel@gnu.org \
    --cc=xma@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).