zsh-workers
 help / color / mirror / code / Atom feed
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
	


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