Home   Info   DevZone   Wiki   UsersWeb  |  MainWeb  |  InfoWeb  |  DevZoneWeb  |  SupportWeb
[ DistributionTerms ] [ not logged in ] [ Web: Imported ] goto:  options [ get info on or edit ] [ login or new user ] [ list of topics, hubs & nodes, or recent changes ]

DistributionGroup; JOSDistribution

Article contributed by GilbertHerschberger (28 February 2000).

Introduction

Just so we can all speak the same language, consistent terminology for JOS distribution should be established. Archive names should be consistent across all JOS-related products. A mirror of JOS-related products has been started at http://cjos.sourceforge.net/redist/mirror .

It is critical for others to understand at-a-glance what we distribute. JOSDistribution should be more like distribution for Linux. This is documented in Linux Programmer's Reference, a book I picked up at Barnes & Noble this weekend. I'm sure you'll find it at your local bookstore.

On Linux, a shared library can be application-specific or not. When it is application-specific, one application depends on it. Such a library is stored in the application's directory.

A common library, on the other hand, is used by more than one application. Such a library is stored, not in an application's directory, but in a system-wide directory. Common libraries are often installed in /lib and /usr/lib.

The requirements for a common library is more strict than for an application-specific library. When a common library is not backward compatible it must be given a new name. Otherwise, applications that depend on the old interface will be unreliable. On the honor system, a common library must remain backward-compatible as long as the library has the same name.

Proposal

The following naming convention provides a unique distribution name for each release of a JOS-related product.

• Form 1: major . minor - release

  This form is typically used for application products. An application is a end-user product. A new release of an application might be intended to replace all previous releases. When there are no other systems dependent upon your application, you are not required preserve system-level compatibility.

  Jext is an application. Its version is 2.7.0. Version 2.7.0 has been released three times. Under form 1, its archive might be named like this:

  jext-2.7.0-3.zip

• Form 2: major prototype - release

  This form is typically used for system products. A system product is an API, framework, library or subsystem. A new release of a system product cannot replace previous releases when there are other applications and subsystems dependent upon it. A system product can be removed only when all products that depend on it are upgraded or removed.

  Smart API is an API and framework. Its current versions are 1a, 1b and 2b. Version 2b does not replace, but depends on versions 1a and 1b. Version 2b has been released six times. Under form 2, the next archive might be named like this:

  smartapi-2b-7.zip

Compatibility

Version and release are used to help others understand what kind of backward compatibility has been preserved. The version should remain the same for as long as the product is compatible. After fixing a bug in a product, the product should be re-distributed using the same version and a new release.

A product can be distributed in more than one archive file format. It is important for archives that contain the same thing to have similar names.

zip2tgz Do you know of a Java-based archive conversion program? If not, would you like to build one? I need to convert .zip files to .tgz files. I already have a .zip file with everything I want to distribute. In fact, the .zip file is stored on my Linux server. Instead of re-creating the archive from scratch, I would like to convert the .zip file to an equivalent .tgz file.

A product can be distributed in different editions. It is important for different editions to have similar names.

Definitions

This is a revised list of distribution terms. These are the terms I am going to use in the future.

• Version

  A version of a product must be closely related to its design (or intended design). A version is a pair of numbers separated by a dot. First, the major version indicates the prerequisites, assumptions and premise for the product. You can let others know that you are changing the rules in a major way by upgrading the major version number. (The minor version is reset to zero.)

  Second, the minor version indicates a specific implementation of the design. It might take more than one implementation to meet the design goals of a major version. You can let others know that you are changing the design again by upgrading the minor version number. (The release number is reset to zero.)

  A minor version does not change when fixing defects in implementation. For Java, a minor version must change when public or protected methods are changed. Under some circumstances, a minor version does not need to change when introducing new classes and/or new packages.

  Previously, I have been using release to indicate a pair of version and prototype. In Release 1a, '1' is the major version and 'a' is the minor version or prototype.

  Extreme reuse requires that version 1b does not replace version 1a. Version 1b does not need to provide any interface or class found in version 1a. This is unlike products labeled with n.n, where version 1.1 replaces version 1.0.

• Release

  When a product is packaged for distribution, a snapshot is created. A snapshot is uploaded to a website or copied to a diskette or CD-ROM. One version of a product might have one or more snapshots distributed. Each snapshot is a release and has its own unique release number. Release numbers start with one (1).

  Previously, I have been using distribution to uniquely identify each snapshot. Each snapshot is meant for distribution.

• Build

  This is different and separate from a build. It might take more than one attempt to build a snapshot worthy of distribution. Builds are used internally to keep track of which build succeeded and which failed during testing.

  I have been using a timestamp to indicate each build and will continue to do so.

Transition

It might take a while to transition from release (version-prototype) to version (major.minor) release.

Content of these pages are owned and copyrighted by the poster.
Hosted by: