Package Versioning

Below each package directory there can be one or more version sub-directories, named after the versions. This is a requirement of the component framework: it must be possible for users to install multiple versions of a package and select which one to use for any given application. This has a number of advantages to users: most importantly it allows a single component repository to be shared between multiple users and multiple projects, as required; also it facilitates experiments, for example it is relatively easy to try out the latest version of some package and see if it makes any difference. There is a potential disadvantage in terms of disk space. However since eCos packages generally consist of source code intended for small embedded systems, and given typical modern disk sizes, keeping a number of different versions of a package installed will usually be acceptable. The administration tool can be used to remove versions that are no longer required.

The version current is special. Typically it corresponds to the very latest version of the sources, obtained by anonymous CVS. These sources may change frequently, unlike full releases which do not change (or only when patches are produced). Component writers may also want to work on the current version.

All other subdirectories of a package correspond to specific releases of that package. The component framework allows users to select the particular version of a package they want to use, but by default the most recent one will be used. This requires some rules for ordering version numbers, a difficult task because of the wide variety of ways in which versions can be identified.

1. The version current is always considered to be the most recent version.

2. If the first character of both strings are either v or V, these are skipped because it makes little sense to enforce case sensitivity here. Potentially this could result in ambiguity if there are two version directories V1.0 and v1.0, but this will match the confusion experienced by any users of such a package. However if two subsequent releases are called V1.0 and v1.1, e.g. because of a minor mix-up when making the distribution file, then the case difference is ignored.

3. Next the two version strings are compared one character at a time. If both strings are currently at a digit then a string to number conversion takes place, and the resulting numbers are compared. For example v10 is a more recent release than v2. If the two numbers are the same then processing continues, so for v2b and v2c the version comparison code would move on to b and c.

4. The characters dot ., hyphen - and underscore _ are treated as equivalent separators, so if one release goes out as v1_1 and the next goes out as v1.2 the separator has no effect.

5. If neither string has yet terminated but the characters are different, ASCII comparison is used. For example V1.1b is more recent than v1.1alpha.

6. If one version string terminates before the other, the current character determines which is the more recent. If the other string is currently at a separator character, for example v1.3.1 and v1.3, then the former is assumed to be a minor release and hence more recent than the latter. If the other string is not at a separator character, for example v1.3beta, then it is treated as an experimental version of the v1.3 release and hence older.

7. There is no special processing of dates, so with two versions ss-20000316 and ss-20001111 the numerical values 20001111 and 20000316 determine the result: larger values are more recent. It is suggested that the full year be used in such cases rather than a shorthand like 00, to avoid Y2100 problems.

8. There is no limit on how many levels of versioning are used, so there could in theory be a v3.1.4.1.5.9.2.7 release of a package. However this is unlikely to be of benefit to typical users of a package.

The version comparison rules of the component framework may not be suitable for every version numbering scheme in existence, but they should cope with many common cases.