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.po...@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 <garydgreg...@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 <boa...@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.po...@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 <garydgreg...@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-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >> >> >> >> >> >> -- >> Matt Sicker <boa...@gmail.com> >> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@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
