After reading some of the responses to this, I think I have to agree with Elias. Trace is an addition, not a subtraction, so it shouldn't hurt anyone. Besides, previous Log4j-1.2.x releases have added features. I'm not sure why this should be any different? Given the fact that the head will take some time to get to a stable release point, I think any eariler statement that the 1.2.x branch should be all but frozen becomes null and void. We shouldn't be breaking the existing API, but I see no reason not to add features and bugfixes to 1.2.x. Having a whole separate version number for a release with minor changes that doesn't break existing functionality seems both confusing and unnecessary.
As for 1.5 -vs- 2.0, I guess that kind of makes sense. Then again, we could just bite the bullet and make the changes we'd like to make and just call it 2.0. In any case, I'm not going to be able to put much time into this as work and other things have been keeping me pretty busy. As such, I'm +0 to the changes proposed by Mark. In other words, I defer to those who are taking a more active development role. Jake Quoting Mark Womack <[EMAIL PROTECTED]>: > OK, consolidating the dicussions we have had the past few days, I would like > to propose the following: > > 1) Release 1.2.11 with JMS build fix, maybe some other critical fixes > (action item: determine the other fixes). Timeframe is almost immediate, > within the next 2 weeks. > > 2) Abandon the 1.3 version number, the main branch becomes version 1.5 > below. > > 3) Release a 1.4 version with the TRACE change and other fixes that will > make life happier for the user base (action item: determine the other > changes). No major structural changes. Just most "important" bugfixes. > The base of the 1.4 code would start from the v1_2branch. Timeframe is > within a month of the 1.2.11 release. > > 4) Release a 1.5 version based on the current main branch. This would be > what we are calling v1.3 today. Timeframe: release of first final version > by 10/2005. > > Exact timeline for the 1.5 version is TBD, but I think we have discussed the > basics. I am not proposing we change the version to 2.0. Again, to me that > means much bigger changes, and we should reserve that version number for > when we want to make the bigger changes. > > I am +1 on the above, and I am committing to make it happen. I am willing > to be the release manager for the proposed versions. We will all need to > focus and do what we need to complete these releases, especially v1.5. > > -Mark > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
