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
