tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <jfrederic.cl...@fujitsu-siemens.com>
Subject Re: #define JK_VERSION in j-t-c (doesn't exist)
Date Fri, 15 Jun 2001 11:34:42 GMT
Andy Armstrong wrote:
> 
> GOMEZ Henri wrote:
> >
> > >Ah. So it's really the jk version I need then so people can build the
> > >connector whether they have the latest j-t-c source or something like
> > >the Tomcat 3.2 source distro. It would be useful to have an API version
> > >number somewhere.
> >
> > * mod_jk in TC 3.2 is +/- frozen (only major bugs fixe) :
> >
> >  we could version it : 1.0.x
> >
> > * mod_jk in TC 3.3 is not frozen but there will be no major feature added :
> >
> >  we could version it : 1.1.x
> >
> > * mod_jk in J-T-C will continue its evolution :
> >
> >  we could version it : 1.2.x
> >
> > >How about
> > >
> > >#define JK_EXPOSED_VERSION ("mod_jk/1.1a1")  <== exists now
> > >#define JK_VERSION 1                         <== proposed
> > >
> > >in jk_global.h? There should be some defined mapping between
> > >the version
> > >string and the number too I suppose.
> >
> > May we use something like Apache 2.0 :
> >
> > #define JK_MODULE_BASEPRODUCT   "mod_jk"
> > #define JK_MODULE_BASEREVISION  "1.2.0-dev"
> > #define JK_MODULE_BASEVERSION   JK_MODULE_BASEPRODUCT "/"
> > JK_MODULE_BASEREVISION
> >
> > #define JK_EXPOSED_VERSION              JK_MODULE_BASEVERSION
> 

These things should in a version.h.in file and the version.h file should be
included when needed.
That some configure related thing. I have already PACKAGE and VERSION prepare
for that.

> OK, but I was thinking of something numeric so it could easily be tested
> at compile time, for example
> 
> #if defined(JK_VERSION) && JK_VERSION >= 1
>     ... newer stuff ...
> #endif

Like it is in the Linux Kernel (LINUX_VERSION_CODE) ;-)

> 
> Strings are fine for user readable versioning, but hard to test at
> compile time.

But it makes only sense if someone want to use a new module with a old core
code.
That means a protocol developed in 1.3.x could be used in 1.2.x.
Well could be nice, but difficult to handle. Backport a new protocol to an old
mod_jk!

> 
> > But what do you means by users building from j-t-c or 3.2/3.3 ?
> 
> I think the two groups of people who will be interested in the source
> for this (and other) connectors are:
> 
> a) People using one of the stable releases and wanting to use it with
> the web server of their choice. They will have downloaded the
> appropriate Tomcat source and may have grabbed the connector source from
> either free.tagish.net or as part of the latest j-t-c release.
> 
> b) People working on the cutting edge j-t-c stuff who will be using the
> latest versions of everything.

? That is CVS ? 

> 
> Ideally I'd like the source for the connector to be the same in either
> case with conditional stuff to include functionality required by later
> jk versions. I assume this would be useful for other connector
> developers too.
> 
> As to the mapping between textual versions and numeric one way to do it
> would be to reserve a certain number of digits for each part of the
> version string so you'd have something like this:
> 
>      1.0.1 ==>  10001
>     12.3.6 ==> 120306

;-)

> 
> which has the advantage that the numerical representation increases
> monotonically and linearly with increases in textual version.
> 
> --
> Andy Armstrong, Tagish

Mime
View raw message