DN511878801

Subject: Validating package versions (Was Re: Version numbers for pure tcl libraries) - DN [1]

Hemang Lavana <hlavana@cisco.com> - 12 Aug 1999 - comp.lang.tcl

 Thank you all for your input on this issue. Based on the discussion on
 this thread, I came to the conclusion that using even/odd version
 numbers for stable/alpha,beta releases would introduce more complexity
 and confusion then providing a clean solution.

 I decided to modify tcl8.0.5/generic/tclPkg.c to do the following:
     1. Version numbers are allowed to have at most one alphabetic
 character, limited to either 'a' or 'b', corresponding to alpha/beta
 releases. The character 'a' or 'b' can occur only where a period (.) is
 allowed to be placed in a version number. Thus, examples of valid
 version numbers are 8.0, 8.0b1, 8.2.1b2, 8.2a3.1, etc. and examples of
 invalid version numbers are b8.0, 8.2.1b, 8.0a2b3, 8.0b2b3.

     2. Packages with alpha/beta version numbers are assumed to be *not*
 compatible with any of the stable releases, nor with one another (ie.
 alpha with beta), so a simple "package require name" will never load an
 alpha/beta release, but only the latest stable release.

     3. To load an alpha or beta version, use "package require -exact name
 8.0b1". It is necessary to specify the -exact option, otherwise it will
 always load the latest stable release even if "package require name
 8.0b1" is invoked.

 These modifications will work seamlessly with the current package
 require mechanism. However, the restriction in (3) to specify the -exact
 option is not very convienient. Therefore, I would also like to see the
 following changes:
     (1) if "package require name 8.0b1" is invoked, it should try to load
 the latest beta version available, such as 8.0b3.
     (2) Two new options "-alpha" and "-beta" should be added to the package
 command, so that "package require -beta name" will only load the
 (latest) beta version, if available.

 However, implementing these would require quite a bit of modifications
 to tclPkg.c and also to a few C APIs, such as Tcl_PkgRequire (to accept
 the -alpha/-beta options).

 I am interested in knowing what other possibilities exist.

 Hemang.

 Don Porter wrote:
 >
 > In article <37B004D5.7BAF88CA@spam.com>, Mo  <no@spam.com> wrote:
 > > % package require foo 8.0
 > > 8.1.1
 > >
 > > I would argue that this is not what most people would expect.
 > > I would think that if a person gives a "major.minor" verison
 > > number, they would expect it to match "major.minor.*" not
 > > "major.*".
 >
 > Thanks for the clarification.
 >
 > As I see it, the [package require] command is the script's chance to
 > make a statement about what public interface it needs from the package.
 > Any version of the package which meets the interface requirements
 > could be loaded with no ill effects.  If we make the assumption
 > that later releases are supposed to be improvements on earlier ones,
 > then [package require] should load the latest installed release which
 > claims compatibility with the required release.
 >
 > The way [package require] is written, the assumption is that
 > backward public interface compatibility is maintained through all
 > releases which share the same major version number.  Thus, it
 > makes sense for [package require foo 8.0] to load foo 8.1.1.
 >
 > If it seems more natural to you for [package require foo 8.0]
 > to ignore the foo 8.1.1 installation and load foo 8.0.2
 > instead, then I take it you prefer a convention where an increment
 > in the minor version number is what indicates a break in backward
 > compatibility.  Perhaps you've grown to expect incompatibilities
 > at minor releases from recent history :( .
 >
 > That's a perfectly acceptable convention to adopt, except:
 >
 > 1. It's not the way [package require] currently works.
 > 2. It leaves the major number not really indicating anything.
 >    If incompatibilities are OK when the minor increments, then
 >    what ?  They're *really* OK when major increments? :)
 >    This convention gives no guidance when is the right time to
 >    increment the major.  The advantage is that it provides
 >    complete freedom in when to increment the major, so it can be
 >    incremented for valuable non-technical (marketing) reasons.
 > 3. If you want to use the different levels to indicate different
 >    claims about how a release is related to previous releases,
 >    (bug fixes vs. additions to the interface) you need to add one
 >    deeper level.
 >
 >    8.0.0        - initial release of the 8.0 series of releases, all of
 >                 which will support the public interface of 8.0.0.
 >    8.0.0.1      - fixes some bugs
 >    8.0.0.2      - fixes some more bugs
 >    8.0.1        - adds new commands to the public interface, still
 >                 supports all of the 8.0.0 interface.  Any scripts
 >                 which make use of the new commands will have to
 >                 have [package require 8.0.1].
 >    8.0.1.1      - bug fixes
 >    8.0.2        - new interface features
 >    8.1.0        - some part of the 8.0.0 public interface is no longer
 >                 supported.  This starts a new series.
 >    9.0.0        - another new series.  Perhaps 8 --> 9 because our
 >                 PR department says that will get magazines to write
 >                 articles about our "new" product.
 >
 > Now, none of this directly addresses how to fit "alpha" and "beta"
 > releases into the numbering scheme, which is what started the thread.
 > Before any new interface feature appears in a final release, it ought
 > to be released in alpha and beta releases.  In the current Tcl scheme,
 > new features appear when the minor is incremented, so before the
 > release of 8.2, there is the release of 8.2b1, 8.2b2, etc.
 > But these numbers don't fit into the [package] command.  [package]
 > just sees "8.2".
 >
 > Is there a numbering system with a place for alpha and beta releases,
 > yet a set of compatibility rules which lets a later stable release
 > be loaded by a script which requires an earlier stable release when
 > there are intervening test releases?
 >
 > --
 > | Don Porter, D.Sc.   Mathematical and Computational Sciences Division |
 > | donald.porter@nist.gov             Information Technology Laboratory |
 > | http://math.nist.gov/mcsd/Staff/DPorter/                        NIST |
 > |______________________________________________________________________|