You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Mark Womack <mw...@apache.org> on 2005/05/23 06:44:15 UTC
Revisiting Log4j Releases
OK, so maybe I was a bit hasty in having the vote for all the release
numbers, but really, folks can -1 my proposals without having to worry about
my feelings. Really. And, by calling the vote, I want to follow it up with
action, not just have the discussion fad into obscurity.
However you want to name them, it really comes down to the same set of
releases. It is just which confusion one wants to mitigate in the user
base. All options have some amount of confusion, as far as I can tell.
Option 1 - What we have now. 1.2.11 with just jms. 1.2.12 with TRACE and
bug fixes. 1.3 release is the next major release on the cvs head.
Confusion/issue - Adding TRACE to the 1.2 branch can be thought of as a
"new" feature since it does change the api in a way that might not be
expected by 1.2 users.
Option 2 - 1.2.11 with just jms (and maybe throw in the bug fixes for the
current 1.2.12 scheduled release). 1.3 based on last release of 1.2.X with
the TRACE changes and some more deprecation in prep for the next major
release. 1.4 release is the next major release on the cvs head.
Confusion/issue - We've already been releasing version 1.3 alpha versions.
Switching it to just 1.2 + TRACE will need to be explained, plus the
explaining of the new 1.4 version. I guess we could do a simultaneous
release of 1.3 and 1.4 so folks have the latest 1.4 alpha (cvs head) to
continue playing with.
Another option I am not seeing (besides skipping version numbers, which no
one really liked)?
We are going to do a 1.2.11 build. I don't think having our most recent
build recalled with no replacement is a good thing. We need to release
something to replace it. I also think that with the next major release
pending until much later this year, we need to release something that users
will find useful. TRACE seems to fit that bill. Fixes for annoying bugs is
a good thing.
What do people want as far as numbering?
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Revisiting Log4j Releases
Posted by Mark Womack <mw...@apache.org>.
----- Original Message -----
From: "Endre Stølsvik" <En...@Stolsvik.com>
To: "Log4J Developers List" <lo...@logging.apache.org>
Sent: Monday, May 23, 2005 5:21 AM
Subject: Re: Revisiting Log4j Releases
>
> But still: Just Get It Done! I am afraid of "a new 1.3" that slips and
> slips..
It won't slip and slip.
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Revisiting Log4j Releases
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Mon, 23 May 2005, Niclas Hedhman wrote:
| On Monday 23 May 2005 12:44, Mark Womack wrote:
| > Option 2 - 1.2.11 with just jms (and maybe throw in the bug fixes for the
| > current 1.2.12 scheduled release). 1.3 based on last release of 1.2.X with
| > the TRACE changes and some more deprecation in prep for the next major
| > release. 1.4 release is the next major release on the cvs head.
|
| +1 (but no time to help realize this)
+1 to 1.2 - 1.3 (not that it matters)
You could even kill Category for my part in the 1.3 - that could be a nice
feature-set for this "minor version".
But why not start using the "major version" number too, here?!
My point is that you'd then have a line of 1.2's that are compatible,
and the 1.3 which is "plugin-compatible" if you have started using the
Logger already (or else you'd have to change your code), with some new
features, and then, finally you'd have the major 2.0 that comes with all
the new stuff. Seems reasonable to me.
At any rate, you don't have to say what the new version will be numbered,
other than that it will be higher than 1.3, e.g. 1.4 or 2.0.
What would log4j developers consider a "2.0" to contain, since there is
such an aversion to this major-jump? A new logging framework, altogether?
|
| > Confusion/issue - We've already been releasing version 1.3 alpha versions.
| > Switching it to just 1.2 + TRACE will need to be explained, plus the
| > explaining of the new 1.4 version. I guess we could do a simultaneous
| > release of 1.3 and 1.4 so folks have the latest 1.4 alpha (cvs head) to
| > continue playing with.
|
| IMHO, confusion here is not so severe, since "bleeding edge" people have a
| higher level of tolerance and understanding. As long as there is a single
| message, I doubt this is a problem.
+1 (well.. I agree..! "Edgers" shouldn't rely on any versioning - a
version is a version when it is shipped, in particular when the stuff in
question is in alpha-stage. Betas should be more locked.)
But still: Just Get It Done! I am afraid of "a new 1.3" that slips and
slips..
Endre.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Revisiting Log4j Releases
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 23 May 2005 12:44, Mark Womack wrote:
> Option 2 - 1.2.11 with just jms (and maybe throw in the bug fixes for the
> current 1.2.12 scheduled release). 1.3 based on last release of 1.2.X with
> the TRACE changes and some more deprecation in prep for the next major
> release. 1.4 release is the next major release on the cvs head.
+1 (but no time to help realize this)
> Confusion/issue - We've already been releasing version 1.3 alpha versions.
> Switching it to just 1.2 + TRACE will need to be explained, plus the
> explaining of the new 1.4 version. I guess we could do a simultaneous
> release of 1.3 and 1.4 so folks have the latest 1.4 alpha (cvs head) to
> continue playing with.
IMHO, confusion here is not so severe, since "bleeding edge" people have a
higher level of tolerance and understanding. As long as there is a single
message, I doubt this is a problem.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org