Skip to main content.
home | support | download

Back to List Archive

Re: [SWISH-E:99] Re: New release of SWISH-Enhanced

From: WWW server manager <webadm(at)not-real.info.cam.ac.uk>
Date: Sat Dec 27 1997 - 14:53:02 GMT
Craig A Summerhill wrote:
> 
> On Wed, 24 Dec 1997, Roy Tennant <rtennant@library.berkeley.EDU> wrote:
> > 
> > We are pleased to announce that version 1.1 of the free Web site indexing
> > software SWISH-Enhanced and its associated interface AutoSwish is now
> > available at http://sunsite.berkeley.edu/SWISH-E/ . They run under Unix
> > and Perl (only required for AutoSwish), and the current release has been
> > installed on tested on Sun Solaris 2.5.1 and DEC Alpha 3.2. 
> 
> Uh, Roy...
> 
> I have a question.  How come when I check the version on the *older*
> version of SWISH-E I aleady have installed here (using the -V flag on
> the compiled binary) it shows version 1.1.1?  And this new release you
> are announcing is version 1.1?  Aren't we going backwards with regard 
> to version numbers?

It looks to me like it was an oversight - the last "original swish" version
identified itself as 1.1.1, and although the swish-e "1.0" version of 
swish.h had a few changes/additions, the version number was untouched...
Similarly, swish.c still identified the program as SWISH rather than SWISH-E
in when asked for the version.

That's now "fixed" in the sense it has been updated to describe itself as 
SWISH-E with the correct version, but there's still a risk of confusion
since people may not notice the subtle distinction between SWISH 1.1.1
(original swish or swish-e 1.0) and SWISH-E 1.1 when deciding which is the
newer version. Releasing a version 1.2 as soon as possible seems like it
would be a sensible move, so that the latest version has the highest number
in either the swish or swish-e numbering scheme. And any bug reports 
mentioning 1.1.1 may need enquiry to establish which version 1.1.1 was 
actually being used!

On a related point (having been prompted to think about such points), it's
also potentially confusing that the distribution files do not clearly
identify the version, leading to the likelihood of accidentally overwriting
the corresponding kits for older versions (which may still be
wanted/needed), and the kits do not include their README or release notes
files. I currently have *three* different kits called "swish-efiles.1.tar" -
the first copy of swish-e 1.0 I fetched, a later bug-fix kit, and now
swish-e 1.1; not very helpful, unless you realise and download each set of
files into a new directory with self-identifying name. 

It would be much less prone to confusion if the distribution files were
named e.g.

  autoswish-1.1.tar.Z
  swish-e-1.1-executable-solaris-2.tar
  swish-e-1.1-source.tar

and for the README and release notes files to be included in the kits (as 
well as being available separately so you can look at them before deciding 
whether you want to fetch the kits). This would mean that installation 
instructions etc., would need either to be updated for each version, or 
amended to be version-independent (identifying the files without tying the 
instructions to particular, version-specific names). 

Similarly, the version number (in swish.h and the file names) should be
incremented for *any* change to the official distribution kits on the FTP
site - not e.g. left unchanged apart from the modification timestamps as
with the recent bug-fix release - someone reporting a bug is unlikely to
know which version they are using, if neither the program's -V option nor
the distribution files distinguish them.

Unless there's some particular reason for using COMPRESS rather than gzip, 
I'd be inclined to use gzip (hence ...tar.gz filenames) since it seems to
have taken over pretty completely for compressing distribution kits, and is
more likely to spot any damage to the kits than compress. At present
there's no consistency about whether kits are compressed (autoswish is, the
others are not) - and http://sunsite.berkeley.edu/SWISH-E/download.html
mistakenly refers to "autoswish.tar.z" (".z" rather than ".Z") which doesn't
actually exist but would imply a different (pack/unpack) and obsolete (? -
don't think I've ever seen such a file) compression format if that were the
actual name.

These are all minor points in the sense that they don't actually get in the 
way of using the kits, but I feel that tidying them up would be helpful, not 
least perhaps in reducing the risk of muddled bug reports.    

                                John Line
-- 
University of Cambridge WWW manager account (usually John Line)
Send general WWW-related enquiries to webmaster@ucs.cam.ac.uk
Received on Sat Dec 27 07:01:09 1997