From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4370 invoked from network); 24 Apr 2002 08:55:22 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 24 Apr 2002 08:55:22 -0000 Received: (qmail 6973 invoked by alias); 24 Apr 2002 08:55:09 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 17030 Received: (qmail 6954 invoked from network); 24 Apr 2002 08:55:08 -0000 X-VirusChecked: Checked Date: Wed, 24 Apr 2002 09:54:39 +0100 From: Oliver Kiddle To: Zsh hackers list Subject: Re: 4.0.5 ? Message-ID: <20020424085439.GA22700@logica.com> References: <29238.1019041000@csr.com> <000c01c1e615$2ca99ee0$1fc1f2a3@mow.siemens.ru> <1020417172407.ZM13112@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1020417172407.ZM13112@candle.brasslantern.com> User-Agent: Mutt/1.3.28i Sender: Oliver Kiddle On Wed, Apr 17, 2002 at 05:24:07PM +0000, Bart Schaefer wrote: > It would appear that users/4157 could be propagated, but I don't know > how much of _man depends on other recent completion changes. I didn't > look closely at any of the workers articles. There are other changes which I would have propagated but for the fact that some completion functions have diverged a bit. _mount is one particular example where to *easily* merge a bug fix, I'd have had to merge a pile of other changes so I was lazy and left the bug. > There are 6 on the branch that aren't on the dev trunk. 15577 is the > only one that looks even remotely suspicious. 15577 wouldn't be applicable to to dev trunk as it is effectively a subset of 15574 which went only on the dev branch. On Wed, Apr 17, 2002 at 09:46:59PM +0400, Borsenkow Andrej wrote: > ? ???, 17.04.2002, ? 21:24, Bart Schaefer ???????: > > There are entries for 229 article numbers (not necessarily 229 log > > entries) in the dev ChangeLog that do not appear in the branch log. > > (How many do there need to be before we declare 4.2? :-) > > IMHO there can be no 4.2 unless module dependency problem is fixed > (dynamic modules that depend on other dynamic modules). >>From the perspective that the current dev branch is almost as stable as 4.0 it would make some sense to declare a 4.2 to allow the users to benefit from those 229 changes. If we hold out for big changes, they may not happen for a while and then they'll take a while to stabilise. I don't think the long 3.0 - 4.0 gap was ideal. > To remind - it is impossible to dlopen() a shared object that has > unresolved data objects even on Linux, that currently rules out any > solution that encodes dependencies in binary itself. Would it work on platforms like Linux to link modules against those they depend. Using external files would be ugly but I'd mind less if they were only needed on some platforms. Oliver This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.