logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <rgo...@apache.org>
Subject Re: Next Release
Date Fri, 20 Jun 2014 03:21:00 GMT
I will try to deal with the distribution packaging

Sent from my iPad

> On Jun 19, 2014, at 7:38 PM, Remko Popma <remko.popma@gmail.com> wrote:
> 
> 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 <ralph.goers@dslextreme.com> 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 <remko.popma@gmail.com> 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 <garydgregory@gmail.com> 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 <boards@gmail.com>
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 <remko.popma@gmail.com>
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 <garydgregory@gmail.com>
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: log4j-dev-unsubscribe@logging.apache.org
>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Matt Sicker <boards@gmail.com>
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
>>>> 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
>> 

Mime
View raw message