About outstanding issues:
I'm aware of two things: changes to the site for the new logo (incl updating 
the home page announcement)
and ensuring that the log4j-perf module is not included in the distribution. 
This last thing may be easiest accomplished by renaming it so that it doesn't 
match the "log4j-" pattern used in assembly/bin. (Also may need a change in 
assembly/source.)
Perhaps rename to log4j2-perf or just perf?

Going over other Jiras now but so far didn't see any showstoppers. 


Sent from my iPhone

> On 2014/06/20, at 9:23, Ralph Goers <[email protected]> wrote:
> 
> I’m fine with all that.  What bugs need to be fixed before rc2 (if any).  I 
> am hoping I can find the time this weekend to create the release.  
> 
> Ralph
> 
> 
>> On Jun 19, 2014, at 4:37 PM, Remko Popma <[email protected]> wrote:
>> 
>> I think we are actually missing out on a lot of community feedback by not 
>> releasing 2.0. Many people are waiting...
>> 
>> If we want to make this release an RC release instead of GA, I can live with 
>> that, but then we should do our utmost to make the next release GA. 
>> 
>> If we want to avoid branching, then let's agree to only commit bug fixes, 
>> and no new features/refactoring to trunk until after GA. 
>> 
>> Thoughts?
>> 
>> Sent from my iPhone
>> 
>>> On 2014/06/19, at 23:19, Gary Gregory <[email protected]> wrote:
>>> 
>>> It feels to early to create busy work to branch IMO. We should do RC2 first 
>>> and get feedback first IMO.
>>> 
>>> Gary
>>> 
>>> 
>>>> On Thu, Jun 19, 2014 at 10:09 AM, Matt Sicker <[email protected]> wrote:
>>>> I agree with Remko on the branching idea. Yes, it would make sense to make 
>>>> RC2 and if that is sufficiently stable, tag it as 2.0 GA. When we do RC2, 
>>>> it should be copied to branches/2.0 or similar. Then we can continue work 
>>>> for 2.1 in trunk.
>>>> 
>>>> Bug fixes for 2.0 should be done on the 2.0 branch and merged to trunk. I 
>>>> think that works rather well usually.
>>>> 
>>>> 
>>>>> On 19 June 2014 08:25, Remko Popma <[email protected]> wrote:
>>>>> Personally I would like to release a GA as soon as possible. I remember 
>>>>> that in spring of 2013 we were talking about releasing GA that summer, so 
>>>>> we've missed that goal by a year already! I agree with Ralph that I think 
>>>>> the code is ready.
>>>>> 
>>>>> If many people want to release an RC2 first in order to confirm the 
>>>>> stability before releasing the GA, then I would agree with that, but that 
>>>>> would only make sense if we can also agree not to make changes that would 
>>>>> require yet another RC...
>>>>> 
>>>>> I would propose that with RC2 we do a feature freeze. We create a 
>>>>> "2.0-release" branch (or something like that, any name is fine), and we 
>>>>> only commit bug fixes to that branch. After say, one month (what would be 
>>>>> a reasonable time?) we release GA from that branch.
>>>>> 
>>>>> Meanwhile, development for new features, refactoring etc continues on 
>>>>> trunk. Of course any bug fix committed to the 2.0-release branch also 
>>>>> needs to be merged into trunk. 
>>>>> 
>>>>> Perhaps one of the reasons we've not been able to do the 2.0 release 
>>>>> earlier is that currently there is only one branch, trunk, where both bug 
>>>>> fixes and new development happens, which makes it hard to say that "now 
>>>>> we have something that is stable enough to release".
>>>>> 
>>>>> We could also do this the other way around, make trunk the release 
>>>>> branch, and create a "2.1" (or something) branch for new development, 
>>>>> that would work too. The point is, we want to be able to add new features 
>>>>> and refactor on the one hand, and on the other hand we want to stabilize 
>>>>> the code for the GA release, and I think separate branches will help us 
>>>>> accomplish that.
>>>>> 
>>>>> Remko
>>>>> 
>>>>> 
>>>>>> On Thu, Jun 19, 2014 at 8:47 PM, Gary Gregory <[email protected]> 
>>>>>> wrote:
>>>>>> To me it feels like another RC would be best. So many changes went in 
>>>>>> since RC 1 that feedback and community testing are needed. If things are 
>>>>>> stable with RC 2 then we can release. There also one non trivial 
>>>>>> issue/feature I'll ask about ASAP on the ML.
>>>>>> 
>>>>>> Gary
>>>>>> 
>>>>>> 
>>>>>> -------- Original message --------
>>>>>> From: Ralph Goers
>>>>>> Date:06/19/2014 00:57 (GMT-05:00)
>>>>>> To: Log4J Developers List
>>>>>> Subject: Next Release
>>>>>> 
>>>>>> We are overdue for a release. The only question I have is whether it 
>>>>>> should be rc2 or GA.  
>>>>>> 1. Are there any open issues that are blockers to a GA release?
>>>>>> 2. Is everyone comfortable with the state of the code for a GA release?
>>>>>> 
>>>>>> For me, I am not aware of any blockers and I think the code is good. The 
>>>>>> only thing I am wondering is with all the changes that have been made 
>>>>>> from rc1 what risk there is with this release being GA.  I suppose one 
>>>>>> possibility would be to release rc2 and then do GA after just a few 
>>>>>> weeks.
>>>>>> 
>>>>>> Thoughts?
>>>>>> 
>>>>>> Ralph
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>> For additional commands, e-mail: [email protected]
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Matt Sicker <[email protected]>
>>> 
>>> 
>>> 
>>> -- 
>>> E-Mail: [email protected] | [email protected] 
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com 
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
> 

Reply via email to