From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10945 invoked from network); 1 May 1999 01:43:40 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 1 May 1999 01:43:40 -0000 Received: (qmail 6116 invoked by alias); 1 May 1999 01:43:34 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6179 Received: (qmail 6107 invoked from network); 1 May 1999 01:43:33 -0000 Message-Id: <199904302324.TAA20048@ocalhost> Content-Type: text/plain MIME-Version: 1.0 X-Image-URL: http://www.peak.org/~luomat/luomat@peak.org.tiff In-Reply-To: <199904281813.LAA21906@bebop.clari.net> From: Timothy J Luoma Date: Fri, 30 Apr 1999 19:24:34 -0400 To: Wayne Davison Subject: Re: yet another undesired 3.1.5-pws-15 change cc: zsh-workers@sunsite.auc.dk References: <199904281813.LAA21906@bebop.clari.net> Replying to message of Wed, 28 Apr 1999 11:13:33 -0700 from Wayne Davison 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