From: Timothy J Luoma <tjlists@bigfoot.com>
To: Wayne Davison <wayne@clari.net>
Cc: zsh-workers@sunsite.auc.dk
Subject: Re: yet another undesired 3.1.5-pws-15 change
Date: Fri, 30 Apr 1999 19:24:34 -0400 [thread overview]
Message-ID: <199904302324.TAA20048@ocalhost> (raw)
In-Reply-To: <199904281813.LAA21906@bebop.clari.net>
Replying to message of Wed, 28 Apr 1999 11:13:33 -0700
from Wayne Davison <wayne@clari.net>
regarding ``Re: yet another undesired 3.1.5-pws-15 change ''
> Timothy J Luoma writes:
> > ps -- there seem to be a LOT of these types of changes in
> > 3.1.5.... I wish there were more consideration given to keeping
> > things consistent for those who upgrade...
>
> It sounds like you aren't aware that all the 3.1.x releases are in
> development. The release code-base is currently 3.0.x, with 3.0.6
> just about to be released. There are bound to be inconsistencies
> (that certainly need to be found and fixed) in the most recent
> development code, so if you're expecting a nice, safe upgrade (rather
> than helping out with the development), you should be using the
> 3.0.x source.
I understand that they are "in development" but are you suggesting that I
wait until the release has been "finalized" to note "hey, this upgrade breaks
stuff"?
When the "final" release comes about, it should be (imo) ready to drop in as
a replacement, meaning that users will _not_ notice any changees unless they
want to take advantage of them.
The "default" behavior should not change between releases. For that to
happen, there need to be people who are not only checking how new features
work, but how old features work.
Waiting until development is "finished" seems foolish.... after all, are the
ZSH folks going to want to go back in and start patching things again? Are
sysadmins going to be happy when they install the newest "final" version only
to find out that it isn't backward-compatible, and they either have to a)
have all their users change the way they work or b) reinstall an older
version?
Maybe I have some assumptions which are not shared by all:
Don't we want people to use the newest version of zsh (when ready, not beta
version), assuming it will have fewer bugs?
If NO, why not?
If YES, then does it not also follow that the latest zsh ought to be
backwards-compatible?
If NO, then how do "we" expect sysadmins to respond (and users for
that matter)? Do we expect them to tweak their various files
because things have changed?
I can tell you that I'm not as apt to install the latest version if it is
going to break ENV settings, functions, etc.
TjL
next prev parent reply other threads:[~1999-05-01 1:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-04-23 10:14 Timothy J Luoma
1999-04-28 18:13 ` Wayne Davison
1999-04-30 23:24 ` Timothy J Luoma [this message]
1999-04-23 10:59 Sven Wischnowsky
1999-04-24 3:11 ` Timothy J Luoma
1999-04-25 13:44 ` Peter Stephenson
1999-04-25 14:35 ` Geoff Wing
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199904302324.TAA20048@ocalhost \
--to=tjlists@bigfoot.com \
--cc=wayne@clari.net \
--cc=zsh-workers@sunsite.auc.dk \
/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.vuxu.org/mirror/zsh/
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 NNTP newsgroup(s).