I believe the logo change should be just replacing the existing logo with the new one with the same size. Ideally the new one would just replace the old one with the same name. I haven't looked to see if that is appropriate.
Sent from my iPad > On Jun 19, 2014, at 7:38 PM, Remko Popma <remko.po...@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.go...@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.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 >>
