68 lines
		
	
	
		
			3.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			68 lines
		
	
	
		
			3.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
|                                   _   _ ____  _     
 | |
|                               ___| | | |  _ \| |    
 | |
|                              / __| | | | |_) | |    
 | |
|                             | (__| |_| |  _ <| |___ 
 | |
|                              \___|\___/|_| \_\_____|
 | |
| 
 | |
| Version Numbers and Releases
 | |
| 
 | |
|  Curl is not only curl. Curl is also libcurl. They're actually individually
 | |
|  versioned, but they mostly follow each other rather closely.
 | |
| 
 | |
|  The version numbering is always built up using the same system:
 | |
| 
 | |
|         X.Y[.Z][-preN]
 | |
| 
 | |
|  Where
 | |
|    X is main version number
 | |
|    Y is release number
 | |
|    Z is patch number
 | |
|    N is pre-release number
 | |
| 
 | |
|  One of these numbers will get bumped in each new release. The numbers to the
 | |
|  right of a bumped number will be reset to zero. If Z is zero, it may not be
 | |
|  included in the version number. The pre release number is only included in
 | |
|  pre releases (they're never used in public, official, releases).
 | |
| 
 | |
|  The main version number will get bumped when *really* big, world colliding
 | |
|  changes are made. The release number is bumped when big changes are
 | |
|  performed. The patch number is bumped when the changes are mere bugfixes and
 | |
|  only minor feature changes. The pre-release is a counter, to identify which
 | |
|  pre-release a certain release is.
 | |
| 
 | |
|  When reaching the end of a pre-release period, the version without the
 | |
|  pre-release part will be released as a public release.
 | |
| 
 | |
|  It means that after release 1.2.3, we can release 2.0 if something really big
 | |
|  has been made, 1.3 if not that big changes were made or 1.2.4 if mostly bugs
 | |
|  were fixed. Before 1.2.4 is released, we might release a 1.2.4-pre1 release
 | |
|  for the brave people to try before the actual release.
 | |
| 
 | |
|  Bumping, as in increasing the number with 1, is unconditionally only
 | |
|  affecting one of the numbers (except the ones to the right of it, that may be
 | |
|  set to zero). 1 becomes 2, 3 becomes 4, 9 becomes 10, 88 becomes 89 and 99
 | |
|  becomes 100. So, after 1.2.9 comes 1.2.10. After 3.99.3, 3.100 might come.
 | |
| 
 | |
|  All original curl source release archives are named according to the libcurl
 | |
|  version (not according to the curl client version that, as said before, might
 | |
|  differ).
 | |
| 
 | |
|  As a service to any application that might want to support new libcurl
 | |
|  features while still being able to build with older versions, all releases
 | |
|  have the libcurl version stored in the curl/curlver.h file using a static
 | |
|  numbering scheme that can be used for comparison. The version number is
 | |
|  defined as:
 | |
|         
 | |
|         #define LIBCURL_VERSION_NUM 0xXXYYZZ
 | |
| 
 | |
|  Where XX, YY and ZZ are the main version, release and patch numbers in
 | |
|  hexadecimal. All three numbers are always represented using two digits.  1.2
 | |
|  would appear as "0x010200" while version 9.11.7 appears as "0x090b07".
 | |
| 
 | |
|  This 6-digit hexadecimal number does not show pre-release number, and it is
 | |
|  always a greater number in a more recent release. It makes comparisons with
 | |
|  greater than and less than work.
 | |
| 
 | |
|  This number is also available as three separate defines:
 | |
|  LIBCURL_VERSION_MAJOR, LIBCURL_VERSION_MINOR and LIBCURL_VERSION_PATCH.
 |