I think this makes sense. As a general practice having at least two or three patch releases after a major or minor release is probably a good idea. It is also fair to point out that it is highly unlikely that we would generate a patch release for an older version - once 2.1 is released it is unlikely we would go back and release 2.0.2.
Ralph > On Aug 5, 2014, at 4:19 AM, Gary Gregory <[email protected]> wrote: > > I should have been clearer, sorry. I am suggesting we take a week (or two) > and have a round of bug fixing for a 2.0.2, even if those are just low > hanging fruits. This will give us a "better 2.0", then we do new features. As > a user, that would give me confidence the log4j team is listening to bug > reports before going back to having fun adding new features. > > 2c, > Gary > > Gary > > > -------- Original message -------- > From: Remko Popma > Date:08/05/2014 00:48 (GMT-05:00) > To: Log4J Developers List > Subject: Re: Which direction to focus on next? > > Thanks, Matt. > > Gary, Ralph, what do you think? > Where should we work on new features? I see these options: > > 1. Don't work on new features, or keep new features on our local machines, > don't commit to apache svn. (TBD: until when?) > > 2. Everyone creates separate branches for new features they want to work on. > So Remko would have a binary logging/memmap branch, and a branch for deleting > old rolled-over files, Matt would have a jdbc-batched-inserts branch, etc. > Bugfixes go into trunk. Everyone is free to sync their branch(es) with > trunk's bugfixes or not. > > 3. We create a shared 2.1 branch for new features. Bugfixes go into trunk as > well as the 2.1 branch. > > 4. Both new features and bugfixes are committed to trunk. No branches needed. > > 5. The opposite of option 3: we create a 2.0.2 branch that holds bugfixes > only. Trunk has both new features and bugfixes. > > 6. Any alternatives that I missed? > > Gary, in the past you mentioned you don't like the busywork of maintaining > two branches. I'm fine with that, but to me that means new features can go > into trunk, because I really don't like option 1... > > Thoughts? > > Sent from my iPhone > >> On 2014/08/05, at 11:31, Matt Sicker <[email protected]> wrote: >> >> I think we can easily do bug fixes from the tag. >> >> >>> On 4 August 2014 21:15, Remko Popma <[email protected]> wrote: >>> Well, the thing is, I've been holding back on this and prioritized bugfixes >>> for over a year now in order to get 2.0 out the door. I've really been >>> looking forward to working on these new things. >>> >>> So what am I supposed to do? There will never be an end to new bugs being >>> reported. >>> >>> Not happy, >>> Remko... >>> >>> Sent from my iPhone >>> >>>> On 2014/08/05, at 10:24, Gary Gregory <[email protected]> wrote: >>>> >>>> It seems that there are some fixes and pending bugs since we started the >>>> 2.0.1 vote that would justify a 2.0.2. Then we could do 2.1. My feeling is >>>> that our priority should be to fix 2.0.x as much as possible before adding >>>> more features for a 2.1. IOW, let's stabilize the current features in >>>> 2.0.x, then add complexity and possible bugs with new features. >>>> >>>> Gary >>>> >>>> >>>>> On Mon, Aug 4, 2014 at 8:10 PM, Matt Sicker <[email protected]> wrote: >>>>> Are there any outstanding issues we'd like to address in a 2.0.2 release, >>>>> or should we just start working toward 2.1 now instead? Because if we go >>>>> the 2.1 route of focus, I've got a few branches to merge back together >>>>> (thankfully, git-svn will help a lot in that regard) into trunk. >>>>> >>>>> As Ralph (IIRC) pointed out, we don't need to make an explicit 2.0 branch >>>>> since we can just branch from the 2.0.1 tag itself if necessary. >>>>> >>>>> -- >>>>> 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 >> >> >> >> -- >> Matt Sicker <[email protected]>
