I think we can keep our lives simpler WRT development process by putting out a patch release or two (as Ralph and I suggest), then moving to 2.1. This will leaving branch only to developers who really need/want it.
Gary On Tue, Aug 5, 2014 at 8:45 AM, Matt Sicker <[email protected]> wrote: > I'm perfectly fine with moving to git, but that's mainly because it's what > I use every day as it is. > > > On 5 August 2014 07:26, Ralph Goers <[email protected]> wrote: > >> 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 >>> <http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >>> >> >> >> -- >> Matt Sicker <[email protected]> >> >> > > > -- > Matt Sicker <[email protected]> > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
