I will try but that may not be possible. Ralph
On Jun 19, 2014, at 8:21 PM, Gary Gregory <[email protected]> wrote: > Keep the perf module name as is please. It would make a mess when with other > tooling like mvn eclipse:eclipse that create projects. Now all projects > nicely sort together. > > Gary > > > -------- Original message -------- > From: Remko Popma > Date:06/19/2014 22:38 (GMT-05:00) > To: Log4J Developers List > Subject: Re: Next Release > > 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 >>
