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 <div>-------- Original message --------</div><div>From: Remko Popma <[email protected]> </div><div>Date:06/19/2014 22:38 (GMT-05:00) </div><div>To: Log4J Developers List <[email protected]> </div><div>Subject: Re: Next Release </div><div> </div>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
