1 {-# LANGUAGE Trustworthy #-}

2 {-# LANGUAGE DeriveDataTypeable #-}

4 -----------------------------------------------------------------------------

5 -- |

6 -- Module : Data.Version

7 -- Copyright : (c) The University of Glasgow 2004

8 -- License : BSD-style (see the file libraries/base/LICENSE)

9 --

10 -- Maintainer : libraries@haskell.org

11 -- Stability : experimental

12 -- Portability : non-portable (local universal quantification in ReadP)

13 --

14 -- A general library for representation and manipulation of versions.

15 --

16 -- Versioning schemes are many and varied, so the version

17 -- representation provided by this library is intended to be a

18 -- compromise between complete generality, where almost no common

19 -- functionality could reasonably be provided, and fixing a particular

20 -- versioning scheme, which would probably be too restrictive.

21 --

22 -- So the approach taken here is to provide a representation which

23 -- subsumes many of the versioning schemes commonly in use, and we

24 -- provide implementations of 'Eq', 'Ord' and conversion to\/from 'String'

25 -- which will be appropriate for some applications, but not all.

26 --

27 -----------------------------------------------------------------------------

30 -- * The @Version@ type

31 Version(..),

32 -- * A concrete representation of @Version@

45 {- |

46 A 'Version' represents the version of a software entity.

48 An instance of 'Eq' is provided, which implements exact equality

49 modulo reordering of the tags in the 'versionTags' field.

51 An instance of 'Ord' is also provided, which gives lexicographic

52 ordering on the 'versionBranch' fields (i.e. 2.1 > 2.0, 1.2.3 > 1.2.2,

53 etc.). This is expected to be sufficient for many uses, but note that

54 you may need to use a more specific ordering for your versioning

55 scheme. For example, some versioning schemes may include pre-releases

56 which have tags @\"pre1\"@, @\"pre2\"@, and so on, and these would need to

57 be taken into account when determining ordering. In some cases, date

58 ordering may be more appropriate, so the application would have to

59 look for @date@ tags in the 'versionTags' field and compare those.

60 The bottom line is, don't always assume that 'compare' and other 'Ord'

61 operations are the right thing for every 'Version'.

63 Similarly, concrete representations of versions may differ. One

64 possible concrete representation is provided (see 'showVersion' and

65 'parseVersion'), but depending on the application a different concrete

66 representation may be more appropriate.

67 -}

70 -- ^ The numeric branch for this version. This reflects the

71 -- fact that most software versions are tree-structured; there

72 -- is a main trunk which is tagged with versions at various

73 -- points (1,2,3...), and the first branch off the trunk after

74 -- version 3 is 3.1, the second branch off the trunk after

75 -- version 3 is 3.2, and so on. The tree can be branched

76 -- arbitrarily, just by adding more digits.

77 --

78 -- We represent the branch as a list of 'Int', so

79 -- version 3.2.1 becomes [3,2,1]. Lexicographic ordering

80 -- (i.e. the default instance of 'Ord' for @[Int]@) gives

81 -- the natural ordering of branches.

84 -- ^ A version can be tagged with an arbitrary list of strings.

85 -- The interpretation of the list of tags is entirely dependent

86 -- on the entity that this version applies to.

87 }

93 -- tags may be in any order

98 -- -----------------------------------------------------------------------------

99 -- A concrete representation of 'Version'

101 -- | Provides one possible concrete representation for 'Version'. For

102 -- a version with 'versionBranch' @= [1,2,3]@ and 'versionTags'

103 -- @= [\"tag1\",\"tag2\"]@, the output will be @1.2.3-tag1-tag2@.

104 --

110 -- | A parser for versions in the format produced by 'showVersion'.

111 --

112 parseVersion :: ReadP Version