[Zlib-devel] zlib-1.2.3-cos1

[William A. Rowe, Jr.]

Cosmin Truta wrote:
> On Mon, 15 May 2006, William A. Rowe, Jr. wrote:
> 
>>Cosmin Truta wrote:
>>
>>>- Add ZLIB_VER_MAJOR, ZLIB_VER_MINOR and ZLIB_VER_REVISION in zlib.h,
>>>  for use in win32/zlib1.rc [Polushin, Rowe, Truta]
>>>
>>>  #define ZLIB_VERSION        "1.2.3-cos1"
>>>  #define ZLIB_VERNUM         0x123f
>>>  #define ZLIB_VER_MAJOR      1
>>>  #define ZLIB_VER_MINOR      2
>>>  #define ZLIB_VER_REVISION   3
>>
>>Cosmin, you omitted ZLIB_VER_BUILD (fourth-level numeric signature).
>>
>>It's TBD if this should be always included in the text representation.
> 
> The fourth letter is not the build number, but it's an internal number
> used for the beta versions released by Mark. This cannot correspond with
> the fourth letter used in .rc version number; that number was 0 until
> now, and it can continue to be 0.

Uhm, that's not what is documented in the FAQ; if this is the case the FAQ
is wrong, and your comment above is fine by me.

If it's specific one-off's later on as the FAQ implies, then it should be
the fourth segment of the version number in both the .rc and version tags.
Just because as a win32-developer you are used to the fourth segment being
a rolling 'build' number (at least, that's how MS uses it) there is no
reason it cannot correspond to the sub-subversion number in the .h file.

>>I think it's VERY unhealth to propogate 'modify the version in three
>>places', you retain this behavior unless the net VERNUM and VERSION
>>are computed.
> 
> It's not three places: it's one place, 5-lines-long at the beginning of
> zlib.h. Keeping them in sync is trivial, but if Mark disagrees, he can
> resort to the solution that you originally proposed:
> 
> #define ZLIB_VERNUM_MAJOR  1
> #define ZLIB_VERNUM_MINOR  2
> #define ZLIB_VERNUM_MAINT  4
> 
> #define ZLIB_STRINGIZE_VAL(val) #val
> #define ZLIB_STRINGIZE_TOK(tok) ZLIB_STRINGIZE_VAL( tok )
> 
> #define ZLIB_VERSION ZLIB_STRINGIZE_TOK( ZLIB_VERNUM_MAJOR ) \
>                  "." ZLIB_STRINGIZE_TOK( ZLIB_VERNUM_MINOR ) \
>                  "." ZLIB_STRINGIZE_TOK( ZLIB_VERNUM_MAINT )
> 
> #define ZLIB_VERNUM ( ZLIB_VERNUM_MAJOR << 12 \
>                     | ZLIB_VERNUM_MINOR <<  8 \
>                     | ZLIB_VERNUM_MAINT <<  4 )
> 
> as opposed to:
> 
> #define ZLIB_VERSION        "1.2.4"
> #define ZLIB_VERNUM         0x1240
> #define ZLIB_VER_MAJOR      1
> #define ZLIB_VER_MINOR      2
> #define ZLIB_VER_REVISION   4
> 
> 
> But, as I was saying, I think the latter is better because of many
> reasons. It is easier to read, easier to comprehend, easier to maintain,
> portable across non-ANSI compilers, and also more flexible (otherwise,
> I wouldn't have been able to use "1.2.3-cos1" for ZLIB_VERSION or 0x123f
> for ZLIB_VERNUM). And, no, if we were to consider private zlib
> modifications, I don't think that introducing an extra macro ZLIB_BLAH
> to put in ZLIB_VERNUM as
> 
> #define ZLIB_VERNUM ( ZLIB_VERNUM_MAJOR << 12 \
>                     | ZLIB_VERNUM_MINOR <<  8 \
>                     | ZLIB_VERNUM_MAINT <<  4 \
>                     | (ZLIB_BLAH ? 0 : 0xf)
> 
> is necessarily a good idea, either.
> 
> [So much for my strong opposition ;-)]

Well - Voices are Heard :)  Mark - we pass off this buck at you, and guess
I'll owe you a beer for casting the decision on how things proceed ;-)

Yours,

Bill