You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by rj...@apache.org on 2010/10/21 18:52:56 UTC
svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
Author: rjung
Date: Thu Oct 21 16:52:56 2010
New Revision: 1026064
URL: http://svn.apache.org/viewvc?rev=1026064&view=rev
Log:
Add svn revision to the end of the exposed version.
The exposed version is only used during startup
logging and in the jk status display.
The revision in the jk_version.h file is not
necessarily that of the last change to jk.
If the jk release script is used, it will update
the info.
Modified:
tomcat/jk/trunk/native/common/jk_version.h
Modified: tomcat/jk/trunk/native/common/jk_version.h
URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_version.h?rev=1026064&r1=1026063&r2=1026064&view=diff
==============================================================================
--- tomcat/jk/trunk/native/common/jk_version.h (original)
+++ tomcat/jk/trunk/native/common/jk_version.h Thu Oct 21 16:52:56 2010
@@ -37,7 +37,7 @@
#define JK_VERRC 0
#define JK_RCSTRING "0"
/* Source Control Revision as a suffix, e.g. "-r12345" */
-#define JK_REVISION ""
+#define JK_REVISION "$Revision$"
/************** END OF AREA TO MODIFY BEFORE RELEASING *************/
@@ -65,7 +65,7 @@
#if (JK_VERRC != 0)
#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT "-rc-" JK_RCSTRING
#elif (JK_VERISRELEASE == 1)
-#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT
+#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT JK_REVISION
#else
#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT "-dev" JK_REVISION
#endif
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
Posted by Mladen Turk <mt...@apache.org>.
On 21/10/2010 20:36, Rainer Jung wrote:
>
>
> On 21.10.2010 20:01, Mladen Turk wrote:
>> On 10/21/2010 06:52 PM, rjung@apache.org wrote:
>>> Author: rjung
>>> -#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT
>>> +#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT JK_REVISION
>>
>> Ok, it seems I have to do it officially, so here it is:
>> -1 veto
>> Please revert adding this to the exposed version.
>> (or at least make it compile time definable)
>
> Why? Technical reason?
>
Technical? none.
However it looks like some test version with ServerTokens
> - I do not plan to keep it in this broken format, instead adding " (xyz)" at the end
>
But why? What is your technical reason for adding it?
We have *version* already. Adding extra crap at the end is just ...
> - there will be a difference between the version added at the end of the internal version string of Apache (o suffix) and the one logged during init (with suffix)
>
Don get this line
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
Posted by Rainer Jung <ra...@kippdata.de>.
On 21.10.2010 20:01, Mladen Turk wrote:
> On 10/21/2010 06:52 PM, rjung@apache.org wrote:
>> Author: rjung
>> -#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT
>> +#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT JK_REVISION
>
> Ok, it seems I have to do it officially, so here it is:
> -1 veto
> Please revert adding this to the exposed version.
> (or at least make it compile time definable)
Why? Technical reason?
- I do not plan to keep it in this broken format, instead adding "
(xyz)" at the end
- there will be a difference between the version added at the end of the
internal version string of Apache (o suffix) and the one logged during
init (with suffix)
> This gives
> Server: Apache/2.2.3 (Red Hat) mod_jk/1.2.31$Revision: 1026064 $
> for a production server!
See above.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
Posted by Mladen Turk <mt...@apache.org>.
On 10/21/2010 06:52 PM, rjung@apache.org wrote:
> Author: rjung
> -#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT
> +#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT JK_REVISION
Ok, it seems I have to do it officially, so here it is:
-1 veto
Please revert adding this to the exposed version.
(or at least make it compile time definable)
This gives
Server: Apache/2.2.3 (Red Hat) mod_jk/1.2.31$Revision: 1026064 $
for a production server!
What a mess I started with a simple release proposal :(
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
Posted by Rainer Jung <ra...@kippdata.de>.
On 21.10.2010 21:21, Mladen Turk wrote:
> On 10/21/2010 09:16 PM, Rainer Jung wrote:
>> On 21.10.2010 20:50, Mladen Turk wrote:
>>
>> OK?
>>
>
> OK :)
> Let's put this to the end.
Peace. I hope it works now as expected.
Do you have anything to add to the changelog?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
Posted by Mladen Turk <mt...@apache.org>.
On 10/21/2010 09:16 PM, Rainer Jung wrote:
> On 21.10.2010 20:50, Mladen Turk wrote:
>
> OK?
>
OK :)
Let's put this to the end.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
Posted by Rainer Jung <ra...@kippdata.de>.
On 21.10.2010 20:50, Mladen Turk wrote:
> On 21/10/2010 20:33, Rainer Jung wrote:
>> On 21.10.2010 19:12, Mladen Turk wrote:
>>>
>>> It means that we won't have
>>> jk-1.2.31 but jk-1.2.31-rSomething even for a release?
>>
>> You mean "It means we won't have?" or "It means we will have?" Guess
>> it's a typo.
>>
>
> Well, I meant we wont have just mod_jk-1.2.31 but rather
> something like mod_jk-1.2.31$Revision: 123456789 $
>
>
>>> Please.
>>
>> It is intended as "1.2.31 (xyz)" where xyz is the numeric revision.
>>
>
> First it doesn't look like that. Second, what does it mean
> from the users point of view.
>
>> Why not? It doesn't find its way into the tarball names etc.
>>
>
> But it does on ServerTokens full, in the logs, etc...
Agreed for ServerTokens (not nice), but for logs I like it because of
the reason given earlier today and repeated below.
> This is a real mess.
> Again I really see what is the *problem* you are trying to solve?
> It's a complete mistery for me.
I wrote:
"My point is: once we circulate something, it should be clearly
distinguishable from anything else we start to circulate. If the RC
doesn't contain in it any indication of RC, you will never be able to
tell, whether someone is using an RC1, RC2 or final release. All of them
will identify itself as 1.2.31."
Sebb wrote:
"If you wish to distinguish the contents, then one possible solution is
to include the SVN revision somewhere in the code.
That would be useful anyway."
and I liked the idea.
I wrote
"Would you oppose, if I find a simple way of adding the revision number
to the exposed version, like
1.2.31 (r1003456)"
and you didn't reply :(
I wrote
"I want to make it possible to *not* do another vote, *but* in case we
have to do another RC be able to later find out where code in the wild
came from.
Adding to the EXPOSED version does not add anything to the names of
files etc. It is meant to be used only during init logging. That's all."
OK?
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
Posted by Mladen Turk <mt...@apache.org>.
On 21/10/2010 20:33, Rainer Jung wrote:
> On 21.10.2010 19:12, Mladen Turk wrote:
>>
>> It means that we won't have
>> jk-1.2.31 but jk-1.2.31-rSomething even for a release?
>
> You mean "It means we won't have?" or "It means we will have?" Guess it's a typo.
>
Well, I meant we wont have just mod_jk-1.2.31 but rather
something like mod_jk-1.2.31$Revision: 123456789 $
>> Please.
>
> It is intended as "1.2.31 (xyz)" where xyz is the numeric revision.
>
First it doesn't look like that. Second, what does it mean
from the users point of view.
> Why not? It doesn't find its way into the tarball names etc.
>
But it does on ServerTokens full, in the logs, etc...
This is a real mess.
Again I really see what is the *problem* you are trying to solve?
It's a complete mistery for me.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
Posted by Rainer Jung <ra...@kippdata.de>.
On 21.10.2010 19:12, Mladen Turk wrote:
> On 10/21/2010 06:52 PM, rjung@apache.org wrote:
>> Author: rjung
>> /* Source Control Revision as a suffix, e.g. "-r12345" */
>> -#define JK_REVISION ""
>> +#define JK_REVISION "$Revision$"
>>
>> /************** END OF AREA TO MODIFY BEFORE RELEASING *************/
>>
>> @@ -65,7 +65,7 @@
>> #if (JK_VERRC != 0)
>> #define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT "-rc-" JK_RCSTRING
>> #elif (JK_VERISRELEASE == 1)
>> -#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT
>> +#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT JK_REVISION
>
> It means that we won't have
> jk-1.2.31 but jk-1.2.31-rSomething even for a release?
You mean "It means we won't have?" or "It means we will have?" Guess
it's a typo.
> Please.
It is intended as "1.2.31 (xyz)" where xyz is the numeric revision.
Why not? It doesn't find its way into the tarball names etc.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
Posted by Mladen Turk <mt...@apache.org>.
On 10/21/2010 06:52 PM, rjung@apache.org wrote:
> Author: rjung
> /* Source Control Revision as a suffix, e.g. "-r12345" */
> -#define JK_REVISION ""
> +#define JK_REVISION "$Revision$"
>
> /************** END OF AREA TO MODIFY BEFORE RELEASING *************/
>
> @@ -65,7 +65,7 @@
> #if (JK_VERRC != 0)
> #define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT "-rc-" JK_RCSTRING
> #elif (JK_VERISRELEASE == 1)
> -#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT
> +#define JK_EXPOSED_VERSION JK_EXPOSED_VERSION_INT JK_REVISION
It means that we won't have
jk-1.2.31 but jk-1.2.31-rSomething even for a release?
Please.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org