Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
On 10/21/2010 06:52 PM, rj...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
On 10/21/2010 06:52 PM, rj...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
On 21.10.2010 19:12, Mladen Turk wrote: On 10/21/2010 06:52 PM, rj...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
On 21.10.2010 20:01, Mladen Turk wrote: On 10/21/2010 06:52 PM, rj...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
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, rj...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1026064 - /tomcat/jk/trunk/native/common/jk_version.h
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
