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
