Discussion: API freeze, release candidate, GA date

[Nick Williams <ni...@nicholaswilliams.net>]

There have been some inquiries lately, and I think it's time to have the discussion. We have all expressed a desire to release Log4j 2 GA this summer, and I think we need to commit to that. In order to get the discussion going, I'm making the following observations and recommendations:

- Right now we are in a "ramp down" phase. We have never officially discussed this, but if you look at the release notes for the past few betas it's apparent. There have been a handful of major additions to the Core, but most of the changes have been minor improvements and bug fixes—things that could easily happen in the context of a stable release as well. This is definitely a typical ramp down.

- I think it's time to start freezing things and get a release candidate out. Log4j 2's feature set and stability has improved significantly over the eight beta releases. The only major remaining TODO, that I see, is improving the ThrowableProxy for Java 8 users. This may not be completable until late this year or early next, because we are still discussing the options on the Java 8 mailing lists and have not started on the API changes for supporting accessing the data we need efficiently. We also need to test ThrowableProxy on the latest Java 7. I suspect there may be some problems there, but I'm not sure.

- I propose that beta-8 be the last beta, and that we vote for 2.0.0.RC1 on August 12 (thus releasing it on August 15, if all goes well). At this point 1) log4j-api should freeze except additions and fixing bugs that can't be fixed by any other means except to change the API, 2) any abstract classes in log4j-core (such as AbstractAppender) should freeze except additions and fixing bugs that can't be fixed by any other means except to change an abstract class, and 3) any changes that break configuration files that were valid as of 2.0.0.RC1 should be limited only to fixing bugs.

- Assuming we only need one release candidate, which I suspect will be the case, I propose we vote for Log4j 2.0.0.GA on September 16 (thus releasing it on September 19, if all goes well). This will meet the "GA this summer" commitment. At this point 1) log4j-api should freeze, even for additions, except to fix SHOW STOPPER bugs (and even fixing these should be restricted to additions and possibly deprecating methods), 2) log4j-core abstract classes should freeze, even for additions, except to fix SHOW STOPPER bugs, and 3) no future changes should break configuration files that were valid as of 2.0.0.GA, even to fix bugs.

These are my thoughts on the topic. I look forward to the coming discussion. Lets get this released! :-)

Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

Re: Discussion: API freeze, release candidate, GA date

[Ralph Goers <ra...@dslextreme.com>]

I am working on some issues related to ThrowableProxy, although the Java 8 issue isn't necessarily one of them.  That said, I don't really see that as a barrier to a 2.0 GA release.

I am fine with beta8 being the last beta, but I see no point in a 2.0.0.RC1.  I would prefer we just go straight to 2.0 and follow it with a 2.0.1, 2.0.2, etc as needed.  Release candidates are only done to validate the release (i.e. beta8 rc1 and rc2). The betas we have been putting out should be sufficient for getting the feedback required.

As for dates, I am good with pretty much anything but I would prefer it be before September.

Ralph

On Jul 14, 2013, at 8:48 AM, Nick Williams wrote:

> There have been some inquiries lately, and I think it's time to have the discussion. We have all expressed a desire to release Log4j 2 GA this summer, and I think we need to commit to that. In order to get the discussion going, I'm making the following observations and recommendations:
> 
> - Right now we are in a "ramp down" phase. We have never officially discussed this, but if you look at the release notes for the past few betas it's apparent. There have been a handful of major additions to the Core, but most of the changes have been minor improvements and bug fixes—things that could easily happen in the context of a stable release as well. This is definitely a typical ramp down.
> 
> - I think it's time to start freezing things and get a release candidate out. Log4j 2's feature set and stability has improved significantly over the eight beta releases. The only major remaining TODO, that I see, is improving the ThrowableProxy for Java 8 users. This may not be completable until late this year or early next, because we are still discussing the options on the Java 8 mailing lists and have not started on the API changes for supporting accessing the data we need efficiently. We also need to test ThrowableProxy on the latest Java 7. I suspect there may be some problems there, but I'm not sure.
> 
> - I propose that beta-8 be the last beta, and that we vote for 2.0.0.RC1 on August 12 (thus releasing it on August 15, if all goes well). At this point 1) log4j-api should freeze except additions and fixing bugs that can't be fixed by any other means except to change the API, 2) any abstract classes in log4j-core (such as AbstractAppender) should freeze except additions and fixing bugs that can't be fixed by any other means except to change an abstract class, and 3) any changes that break configuration files that were valid as of 2.0.0.RC1 should be limited only to fixing bugs.
> 
> - Assuming we only need one release candidate, which I suspect will be the case, I propose we vote for Log4j 2.0.0.GA on September 16 (thus releasing it on September 19, if all goes well). This will meet the "GA this summer" commitment. At this point 1) log4j-api should freeze, even for additions, except to fix SHOW STOPPER bugs (and even fixing these should be restricted to additions and possibly deprecating methods), 2) log4j-core abstract classes should freeze, even for additions, except to fix SHOW STOPPER bugs, and 3) no future changes should break configuration files that were valid as of 2.0.0.GA, even to fix bugs.
> 
> These are my thoughts on the topic. I look forward to the coming discussion. Lets get this released! :-)
> 
> Nick
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org