There are also legitimate use case for merging 4.x to trunk: If you are working on deprecating stuff and replacing my new apis, you need to often spend lot of work in "sophisticated backwards" :-) To do this development, 4.x is the right place. I finally merge the stuff up to trunk and then remove the deprecations.
The other way round is in most cases not so easy to do, especially when trunk's APIs already changed. Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Michael McCandless [mailto:[email protected]] > Sent: Thursday, June 13, 2013 5:57 PM > To: Lucene/Solr dev > Subject: Re: Where to aim a patch > > On Thu, Jun 13, 2013 at 11:07 AM, Yonik Seeley <[email protected]> > wrote: > > On Thu, Jun 13, 2013 at 7:04 AM, Benson Margulies > <[email protected]> wrote: > >> I'd like to take a run at SOLR-4872 with the goal of getting it into > >> the smallest-numbered release possible. What branch to I start on? > > > > IMO, patches should normally be aimed at trunk and backported. > > "svn merge" tends to make a mess of the target (mergeproperties > > updated so you can't tell at a glance what files a patch actually > > changed), and in general we've tried to keep trunk clean by merging > > from trunk instead of to trunk. > > Is this really true anymore, with latest svn clients (1.7.x)? > > I had always assumed devs are free to merge in either direction ... > whatever their preference is. > > Mike McCandless > > http://blog.mikemccandless.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] For additional > commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
