1 <!-- Copyright (C) 2003 Red Hat, Inc. -->
2 <!-- This material may be distributed only subject to the terms -->
3 <!-- and conditions set forth in the Open Publication License, v1.0 -->
4 <!-- or later (the latest version is presently available at -->
5 <!-- http://www.opencontent.org/openpub/). -->
6 <!-- Distribution of the work or derivative of the work in any -->
7 <!-- standard (paper) book form is prohibited unless prior -->
8 <!-- permission is obtained from the copyright holder. -->
12 >Package Versioning</TITLE
13 ><meta name="MSSmartTagsPreventParsing" content="TRUE">
16 CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
19 TITLE="The eCos Component Writer's Guide"
20 HREF="cdl-guide.html"><LINK
22 TITLE="Package Organization"
23 HREF="package.html"><LINK
25 TITLE="Package Organization"
26 HREF="package.html"><LINK
28 TITLE="Package Contents and Layout"
29 HREF="package.contents.html"></HEAD
40 SUMMARY="Header navigation table"
52 > Component Writer's Guide</TH
68 >Chapter 2. Package Organization</TD
74 HREF="package.contents.html"
88 NAME="PACKAGE.VERSIONS">Package Versioning</H1
90 >Below each package directory there can be one or more version
91 sub-directories, named after the versions. This is a requirement of
92 the component framework: it must be possible for users to install
93 multiple versions of a package and select which one to use for any
94 given application. This has a number of advantages to users: most
95 importantly it allows a single component repository to be shared
96 between multiple users and multiple projects, as required; also it
97 facilitates experiments, for example it is relatively easy to try out
98 the latest version of some package and see if it makes any difference.
99 There is a potential disadvantage in terms of disk space. However
103 > packages generally consist of source code intended for
104 small embedded systems, and given typical modern disk sizes, keeping a
105 number of different versions of a package installed will usually be
106 acceptable. The administration tool can be used to remove versions
107 that are no longer required.</P
109 CLASS="INFORMALFIGURE"
127 > is special. Typically it
128 corresponds to the very latest version of the sources, obtained by
132 >. These sources may change frequently, unlike full
133 releases which do not change (or only when patches are produced).
134 Component writers may also want to work on the
140 >All other subdirectories of a package correspond to specific releases
141 of that package. The component framework allows users to select the
142 particular version of a package they want to use, but by default the
143 most recent one will be used. This requires some rules for ordering
144 version numbers, a difficult task because of the wide variety of ways
145 in which versions can be identified.</P
155 > is always considered to be
156 the most recent version.</P
160 >If the first character of both strings are either <TT
167 >, these are skipped because it makes little
168 sense to enforce case sensitivity here. Potentially this could result
169 in ambiguity if there are two version directories
177 match the confusion experienced by any users of such a package.
178 However if two subsequent releases are called <TT
185 >, e.g. because of a minor mix-up when
186 making the distribution file, then the case difference is ignored.</P
190 >Next the two version strings are compared one character at a time.
191 If both strings are currently at a digit then a string to number
192 conversion takes place, and the resulting numbers are compared.
196 > is a more recent release than
200 >. If the two numbers are the same then processing
201 continues, so for <TT
208 the version comparison code would move on to <TT
219 >The characters dot <TT
229 > are treated as equivalent
230 separators, so if one release goes out as <TT
234 the next goes out as <TT
237 > the separator has no
242 >If neither string has yet terminated but the characters are different,
243 ASCII comparison is used. For example <TT
254 >If one version string terminates before the other, the current
255 character determines which is the more recent. If the other string is
256 currently at a separator character, for example
264 is assumed to be a minor release and hence more recent than the
265 latter. If the other string is not at a separator character, for
269 >, then it is treated as an
270 experimental version of the <TT
278 >There is no special processing of dates, so with two versions
286 the numerical values <TT
293 > determine the result: larger values are
294 more recent. It is suggested that the full year be used in such cases
295 rather than a shorthand like <TT
303 >There is no limit on how many levels of versioning are used, so
304 there could in theory be a <TT
306 >v3.1.4.1.5.9.2.7</TT
308 of a package. However this is unlikely to be of benefit to typical
309 users of a package.</P
313 >The version comparison rules of the component framework may not be
314 suitable for every version numbering scheme in existence, but they
315 should cope with many common cases.</P
335 >There are some issues still to be resolved before it is possible to
339 > sources available via
343 > and full releases of <SPAN
346 > and additional packages in
347 a single component repository. The first problem relates to the
351 > database: if a new package is added via
352 the CVS repository then this requires a database update, but the
353 administration tool is bypassed. The second problem arises if an
354 organization chooses to place its component repository under source
355 code control using <SPAN
358 >, in which case different directories will
359 belong to different <SPAN
362 > servers. These issues will be addressed in a
374 SUMMARY="Footer navigation table"
394 HREF="cdl-guide.html"
403 HREF="package.contents.html"
413 >Package Organization</TD
427 >Package Contents and Layout</TD
projects / karo-tx-redboot.git / blob