Re: managing CHANGES.txt?
On Jun 30, 2011, at 9:00 PM, Robert Muir wrote: > when they look at CHANGES.txt they just want to know what > changed since the last release. +1 - Mark Miller lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: managing CHANGES.txt?
On Thu, Jun 30, 2011 at 6:02 PM, Chris Hostetter wrote: > > : There's no sense in CHANGES being a 'rolling list', when someone looks > : at 4.0 they should be able to see whats DIFFERENT aka what CHANGED > : from the past release. > > I agree completely, the disagreement is *which* past release the list > should be relative to. Definitely, at least we agree on something :) > > I don't know how many more ways i can say it: I believe that the list of > changes for 4.0 should be labled (and contain) "Changes since 3.0" -- > because that is the most recent "past release" sith a common development > history. > Right, I guess this is where I disagree. I think this is a developer-oriented perspective: who cares about development history? A user upgrading from Lucene 3.9 looks at 4.0's CHANGES.txt and wants to know, what has changed since 3.9? maybe they go straight from 3.8, in which case they read the 3.9 section underneath that too, but all of this is WAY easier than seeing all the changes from 3.0 and trying to sort out what the hell is going on. seriously, i think 99% of the time my attitude is "to hell with the users, lets do whats best for the devs since this is our project", but as devs if we want to track things thru branches of development, we can do this with tools like SVN... I think CHANGES.txt is for the users. If we decided to go your route, I would rather nuke CHANGES.txt completely and create it from 'svn log'. But as I said earlier, I don't think users care about the internal details (such as svn branches and stuff) of how we produce our artifacts. If they have 3.9 and they upgrade to 4.0 I think they just want to know the differences: what are the new features, bugs fixed, backwards breaks, how to upgrade, etc. If I go and create my own branch from scratch tonight, code like a madman and produce something i call 'lucene 3.4 release candidate' and everyone votes +1 to release (not likely, but this is totally possible), should its CHANGES.txt really contain all the differences from 3.0? Or should it contain only the differences since the last release (3.3)? I don't think anyone cares how many branches I created or anything like that, when they look at CHANGES.txt they just want to know what changed since the last release. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: managing CHANGES.txt?
: There's no sense in CHANGES being a 'rolling list', when someone looks : at 4.0 they should be able to see whats DIFFERENT aka what CHANGED : from the past release. I agree completely, the disagreement is *which* past release the list should be relative to. I don't know how many more ways i can say it: I believe that the list of changes for 4.0 should be labled (and contain) "Changes since 3.0" -- because that is the most recent "past release" sith a common development history. When we only had a single trunk and the 3.0 release branch was forked from the same place as the 2.9 release branch it made sense to think of the 3.0 changes list as "Changes since 2.9" because they were genuine success of eachother -- any code in 2.9 was by definition in 3.0 unless it was modified/removed by somehting listed in the 3.0 changes. That is not going to be true for 3.3 and 4.0 (or 3.4 and 4.0, or 3.7 and 4.0 or whatever our last 3.x release is before 4.0). The list of changes for a release should always make it clear *exactly* what is differnet between that release and the previous release with common "lineage" of source code -- it may sound weird, but it's what i believe and it's consistent with how we've done bug fix releases in the past -- they've refered to changes since their "parent" release, not since the last calendar release. Since no one seems to agree with me on this, I've tried to let this go (twice!) by stating my position and conceeding that it's not concensus -- but if you keep reviving the argument, i'll happily keep restating my beliefs. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: managing CHANGES.txt?
On Tue, Jun 21, 2011 at 2:47 PM, Chris Hostetter wrote: > You're missing my point entirely. yes it's in the 3.2 section but all > that tells the user is that it was fixed on the 3x branch just prior to > the 3.2 release -- that doesn't give users *any* info about wether that > bug ever affected (or was fixed) on the completely and radically different > 4x branch. There were multiple commits -- the bits are not the same. > Did 4.0 get released somehow without me noticing? Users don't need to see whether the bug affected the 4.x branch. There is no such thing. 4.0 is unreleased: if its a bug in 4.0, I generally add no CHANGES.txt at all, unless its a non-committer contributing the patch, in which case I add their name to the new-4.0-feature-affected-by-the-bug-in-question. There's no sense in CHANGES being a 'rolling list', when someone looks at 4.0 they should be able to see whats DIFFERENT aka what CHANGED from the past release. The only possible use these rolling lists could have is for people using trunk, but thats not its purpose: if you are using trunk, you need to be subscribed to the commits@ list. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: managing CHANGES.txt?
: > But there is no way for someone looking at the CHANGES for 4.0 to know : > for certain that the bits that make up that bug fix are in the 4.0 release : > -- the fact that it's listed in 3.2's CHANGES isn't an assurance, because : > 4.0 comes from a completely different line of development. ... : its in the 4.0 CHANGES.txt, under the 3.2 section. (sigh ... i tried to let this go, i swear i did...) You're missing my point entirely. yes it's in the 3.2 section but all that tells the user is that it was fixed on the 3x branch just prior to the 3.2 release -- that doesn't give users *any* info about wether that bug ever affected (or was fixed) on the completely and radically different 4x branch. There were multiple commits -- the bits are not the same. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: managing CHANGES.txt?
You 'remore prickly than me today Steve :) You are of course free to document anything you see fit. And I'm free to weigh in on my opinion about documenting :) That's how it works indeed, and it's a beautiful system. - Mark On Jun 21, 2011, at 2:08 PM, Steven A Rowe wrote: > Mark, > > Staleness is way better than digging through mail archives, guessing and > getting it wrong, or re-invention. > > Word of mouth doesn't scale. The Lucene/Solr dev community is growing. > > Where I see an opportunity to document current practice, where it is less > than obvious what to do, I will, modulo free time of course. > > Feel free to ignore my idiocy. > > Steve > >> -Original Message- >> From: Mark Miller [mailto:markrmil...@gmail.com] >> Sent: Tuesday, June 21, 2011 1:54 PM >> To: dev@lucene.apache.org >> Subject: Re: managing CHANGES.txt? >> >> On Jun 21, 2011, at 1:47 PM, Steven A Rowe wrote: >> >>> Again, you obviously have a concrete idea of what should be done - can >> you point to a writeup? >>> >>> Thanks, >>> Steve >> >> >> Thank you Robert for keeping Changes pretty. >> >> -1 to more formalization, or "writeups". I've seen the opinions in the >> emails on the topic now and before. Writeups turn into more than they >> should be over time, half the time. They end up stale or over followed. >> >> - Mark Miller >> lucidimagination.com > - Mark Miller lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: managing CHANGES.txt?
On 6/21/2011 at 1:52 PM, Robert Muir wrote: > On Tue, Jun 21, 2011 at 1:47 PM, Steven A Rowe wrote: > > On 6/21/2011 at 1:26 PM, Robert Muir wrote: > > > On Tue, Jun 21, 2011 at 1:23 PM, Steven A Rowe wrote: > > > > Is the CHANGES.txt policy you advocate (and police) written up in > > > > one place? I'm sure you'd like to not have to fix up everybody's > > > > entries > > > > > > It wasn't anything i advocate, I'm just describing what it seems like > > > we do 99% of the time? (in my example, Uwe committed it, and I didnt > > > fix anything) > > > > I'm confused - seems like you're disavowing the role you've been > > playing as CHANGES policeman - yet I've seen at least 10 CHANGES- > > policing commits within the last six weeks?: > > I do disavow this role: when CHANGES.txt is jacked up, i fix it, I > don't complain to anyone about it. I dont understand how this makes me > a policeman? CHANGES janitor??? Echoing Mark M., thanks for scrubbing. I was looking to make it possible for others to share the load, by publicizing the target. Steve
RE: managing CHANGES.txt?
Mark, Staleness is way better than digging through mail archives, guessing and getting it wrong, or re-invention. Word of mouth doesn't scale. The Lucene/Solr dev community is growing. Where I see an opportunity to document current practice, where it is less than obvious what to do, I will, modulo free time of course. Feel free to ignore my idiocy. Steve > -Original Message- > From: Mark Miller [mailto:markrmil...@gmail.com] > Sent: Tuesday, June 21, 2011 1:54 PM > To: dev@lucene.apache.org > Subject: Re: managing CHANGES.txt? > > On Jun 21, 2011, at 1:47 PM, Steven A Rowe wrote: > > > Again, you obviously have a concrete idea of what should be done - can > you point to a writeup? > > > > Thanks, > > Steve > > > Thank you Robert for keeping Changes pretty. > > -1 to more formalization, or "writeups". I've seen the opinions in the > emails on the topic now and before. Writeups turn into more than they > should be over time, half the time. They end up stale or over followed. > > - Mark Miller > lucidimagination.com
Re: managing CHANGES.txt?
On Jun 21, 2011, at 1:47 PM, Steven A Rowe wrote: > > > Again, you obviously have a concrete idea of what should be done - can you > point to a writeup? > > Thanks, > Steve Thank you Robert for keeping Changes pretty. -1 to more formalization, or "writeups". I've seen the opinions in the emails on the topic now and before. Writeups turn into more than they should be over time, half the time. They end up stale or over followed. - Mark Miller lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: managing CHANGES.txt?
On Tue, Jun 21, 2011 at 1:47 PM, Steven A Rowe wrote: > On 6/21/2011 at 1:26 PM, Robert Muir wrote: >> On Tue, Jun 21, 2011 at 1:23 PM, Steven A Rowe wrote: >> > Is the CHANGES.txt policy you advocate (and police) written up in one >> > place? I'm sure you'd like to not have to fix up everybody's entries >> >> It wasn't anything i advocate, I'm just describing what it seems like >> we do 99% of the time? (in my example, Uwe committed it, and I didnt >> fix anything) > > I'm confused - seems like you're disavowing the role you've been playing as > CHANGES policeman - yet I've seen at least 10 CHANGES-policing commits within > the last six weeks?: > I do disavow this role: when CHANGES.txt is jacked up, i fix it, I don't complain to anyone about it. I dont understand how this makes me a policeman? - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: managing CHANGES.txt?
On 6/21/2011 at 1:26 PM, Robert Muir wrote: > On Tue, Jun 21, 2011 at 1:23 PM, Steven A Rowe wrote: > > Is the CHANGES.txt policy you advocate (and police) written up in one > > place? I'm sure you'd like to not have to fix up everybody's entries > > It wasn't anything i advocate, I'm just describing what it seems like > we do 99% of the time? (in my example, Uwe committed it, and I didnt > fix anything) I'm confused - seems like you're disavowing the role you've been playing as CHANGES policeman - yet I've seen at least 10 CHANGES-policing commits within the last six weeks?: http://svn.apache.org/viewvc?rev=1137361&view=rev http://svn.apache.org/viewvc?rev=1137359&view=rev http://svn.apache.org/viewvc?rev=1130564&view=rev http://svn.apache.org/viewvc?rev=1128248&view=rev http://svn.apache.org/viewvc?rev=1128247&view=rev http://svn.apache.org/viewvc?rev=1125127&view=rev http://svn.apache.org/viewvc?rev=1125128&view=rev http://svn.apache.org/viewvc?rev=1125134&view=rev http://svn.apache.org/viewvc?rev=1125135&view=rev http://svn.apache.org/viewvc?rev=1102119&view=rev Again, you obviously have a concrete idea of what should be done - can you point to a writeup? Thanks, Steve
Re: managing CHANGES.txt?
It wasn't anything i advocate, I'm just describing what it seems like we do 99% of the time? (in my example, Uwe committed it, and I didnt fix anything) On Tue, Jun 21, 2011 at 1:23 PM, Steven A Rowe wrote: > Robert, > > Is the CHANGES.txt policy you advocate (and police) written up in one place? > I'm sure you'd like to not have to fix up everybody's entries > > Steve > >> -Original Message- >> From: Robert Muir [mailto:rcm...@gmail.com] >> Sent: Tuesday, June 21, 2011 1:14 PM >> To: dev@lucene.apache.org >> Subject: Re: managing CHANGES.txt? >> >> On Tue, Jun 21, 2011 at 1:09 PM, Chris Hostetter >> wrote: >> > >> > But there is no way for someone looking at the CHANGES for 4.0 to know >> > for certain that the bits that make up that bug fix are in the 4.0 >> release >> > -- the fact that it's listed in 3.2's CHANGES isn't an assurance, >> because >> > 4.0 comes from a completely different line of development. >> > >> >> its in the 4.0 CHANGES.txt, under the 3.2 section. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: managing CHANGES.txt?
Robert, Is the CHANGES.txt policy you advocate (and police) written up in one place? I'm sure you'd like to not have to fix up everybody's entries Steve > -Original Message- > From: Robert Muir [mailto:rcm...@gmail.com] > Sent: Tuesday, June 21, 2011 1:14 PM > To: dev@lucene.apache.org > Subject: Re: managing CHANGES.txt? > > On Tue, Jun 21, 2011 at 1:09 PM, Chris Hostetter > wrote: > > > > But there is no way for someone looking at the CHANGES for 4.0 to know > > for certain that the bits that make up that bug fix are in the 4.0 > release > > -- the fact that it's listed in 3.2's CHANGES isn't an assurance, > because > > 4.0 comes from a completely different line of development. > > > > its in the 4.0 CHANGES.txt, under the 3.2 section. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org
Re: managing CHANGES.txt?
On Tue, Jun 21, 2011 at 1:09 PM, Chris Hostetter wrote: > > But there is no way for someone looking at the CHANGES for 4.0 to know > for certain that the bits that make up that bug fix are in the 4.0 release > -- the fact that it's listed in 3.2's CHANGES isn't an assurance, because > 4.0 comes from a completely different line of development. > its in the 4.0 CHANGES.txt, under the 3.2 section. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: managing CHANGES.txt?
On Fri, Jun 10, 2011 at 9:31 PM, Chris Hostetter wrote: > > Buf for bug fixes we really need to deal with this in a better way. We > need to track *every* bug fix made on a branch, even if they were > backported to an earlier branch. > I think we have? bugfixes are the only case (assuming we go with the plan where we don't go back in time and issue 3.x feature releases after we release 4.x, etc) where we "go backwards". I'll pick LUCENE-3042 as a random one. Its in Lucene 3.2's CHANGES.txt Its in branch-3.0's CHANGES.txt its in branch-2.9's CHANGES.txt its not in trunk's CHANGES.txt, since its fixed in a non-bugfix release before 4.0 will be released. In short, I don't think there is any problem... and as far back as I can see, this is exactly how we have been handling all bugfixes with the 2.9.x and 3.0.x bugfix releases. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: managing CHANGES.txt?
>> >> : we already raised this issue and decided against it for a number of >> : reasons, it was raised on the dev list and everyone voted +1 >> : >> : >> http://www.lucidimagination.com/search/document/a42f9a22fe39c4b4/discussion_trunk_and_stable_release_strategy#67815ec25c055810 >> >> i contest your characterization of "everyone" but clearly i missed that >> thread back when it happened. That only address the issue of 3.x feature >> releases after 4.0 comes out -- but it still doesn't address the porblem >> of bug fixes backported from 4.x to 3.x after 4.0 -- those will still be a >> serious problem if we keep removing things from the trunk CHANGES.txt when >> backporting. > > OK, well everyone that did vote, voted +1. If you disagree please > respond to that thread! I think it would make things confusing if we > released 4.0 say today, then released 3.3 later, and 4.0 couldnt read > 3.3 indexes... but please reply to it. > The release strategy and CHANGES strategy seem different (but related) to me. I agree with the release strategy outlined in that thread, but don't see how it answers questions about maintaining CHANGES.txt The thing that seems wierd is that the historic release info in CHANGES.txt is potentially different then what will presumably be released in the 3.x branch. For example right now, if you take the 3.x lucene/CHANGES and paste them in the right place on trunk, there there are a bunch of diffs for names with accents - have been deleted. (Christian Kohlsch├╝tter via Mike McCandless) + have been deleted. (Christian Kohlschⁿtter via Mike McCandless) but also real differences like: -* LUCENE-2130: Fix performance issue when FuzzyQuery runs on a - multi-segment index (Michael McCandless) - The same exercise in solr/CHANGES.txt reveals lots of differences. Is this expected? It seem more like a by-product of trying to keep things in sync. I suppose that could be fixed with some good To simplify the process, I suggest we remove historic info from /trunk and add point people to the CHANGE in the current stable branch (3.x) -- when /trunk is moved to /branch_4x we would move everything there. ryan - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: managing CHANGES.txt?
On Thu, Jun 9, 2011 at 4:44 PM, Chris Hostetter wrote: > > : > The approach (and the cleanness of the merges) completley breaks down if > : > you start out assuming a feature is targetting 4x, and then later decide > : > to backport it. > : > : you just first move your change to the 3.x section? > > so you're saying that to backport something from trunk to 3x you're > saying the process should be: > * first you should commit a change to trunk's CHANGES.txt moving the > previously commited entry to the appropraite 3.x.y section > * then you should merge the *two* commits to the 3x branch > > ? I think so? I guess in general, most things unless they are super-scary tend to get backported immediately to 3.x (and you know up-front you are going to do this) so in practice this hasn't been a problem? > > : we already raised this issue and decided against it for a number of > : reasons, it was raised on the dev list and everyone voted +1 > : > : > http://www.lucidimagination.com/search/document/a42f9a22fe39c4b4/discussion_trunk_and_stable_release_strategy#67815ec25c055810 > > i contest your characterization of "everyone" but clearly i missed that > thread back when it happened. That only address the issue of 3.x feature > releases after 4.0 comes out -- but it still doesn't address the porblem > of bug fixes backported from 4.x to 3.x after 4.0 -- those will still be a > serious problem if we keep removing things from the trunk CHANGES.txt when > backporting. OK, well everyone that did vote, voted +1. If you disagree please respond to that thread! I think it would make things confusing if we released 4.0 say today, then released 3.3 later, and 4.0 couldnt read 3.3 indexes... but please reply to it. As far as bugfix releases, in lucene we have always had this issue (e.g. if we do 3.2.1 we have the issue now). Thats why we have in our ReleaseTODO a task where we deal with this (and i noticed it had been missing from one of the bugfix 3.0.x releases and fixed that for 3.2). - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: managing CHANGES.txt?
: > The approach (and the cleanness of the merges) completley breaks down if : > you start out assuming a feature is targetting 4x, and then later decide : > to backport it. : : you just first move your change to the 3.x section? so you're saying that to backport something from trunk to 3x you're saying the process should be: * first you should commit a change to trunk's CHANGES.txt moving the previously commited entry to the appropraite 3.x.y section * then you should merge the *two* commits to the 3x branch ? that seems like kind of a pain in the ass considering it still doesn't track reality: the change really was commited to two completly distinct branches of development -- the underlying code changes made to implement a feature/fix might be radically differnet -- both should be tracked. : we already raised this issue and decided against it for a number of : reasons, it was raised on the dev list and everyone voted +1 : : http://www.lucidimagination.com/search/document/a42f9a22fe39c4b4/discussion_trunk_and_stable_release_strategy#67815ec25c055810 i contest your characterization of "everyone" but clearly i missed that thread back when it happened. That only address the issue of 3.x feature releases after 4.0 comes out -- but it still doesn't address the porblem of bug fixes backported from 4.x to 3.x after 4.0 -- those will still be a serious problem if we keep removing things from the trunk CHANGES.txt when backporting. As i've said before... > Arguably we could dedup identical entries so that each entry appears > only once (i suggested this before and now think i was wrong), but that > loses information: people who see that LUCENE-9876 was fixed in 2.9.4 > have no context of wether that fix was in 3.0.2 or 3.0.3 -- to have that > full context it makes sense for each "fix" commited in a branch to > actually be listed in the first release on that branch that the fix was > in. If 4.1 comes out, and then i commit a bug fix to trunk which gets backported to the 3_7 branch and included in a 3.7.1 release it should *still* be in the trunk CHANGES.txt for inclusion in the 4.2 CHANGES.txt. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: managing CHANGES.txt?
On Thu, Jun 9, 2011 at 3:22 PM, Chris Hostetter wrote: > > : you just commit it to the version it was added. > : > : For example, if you are adding something to 3x and trunk, commit it to > : the 3x section of trunk's CHANGES.txt > : then when you svn merge, there will be no merge conflict, it will just work. > > That assumes you know, before commiting to trunk, that it will (or wont) > be backported to 3x. > > The approach (and the cleanness of the merges) completley breaks down if > you start out assuming a feature is targetting 4x, and then later decide > to backport it. you just first move your change to the 3.x section? > > it will also break down in even more fun and confusing ways if/when we > have our first 4.0 release and then someone pushes for having a 3.42 > feature release after that (to push out some high value features to people > not yet ready to upgrade to 4.0) because the changes legitimately need to > show up in both the 3.42 and 4.1 release notes. we already raised this issue and decided against it for a number of reasons, it was raised on the dev list and everyone voted +1 http://www.lucidimagination.com/search/document/a42f9a22fe39c4b4/discussion_trunk_and_stable_release_strategy#67815ec25c055810 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: managing CHANGES.txt?
: you just commit it to the version it was added. : : For example, if you are adding something to 3x and trunk, commit it to : the 3x section of trunk's CHANGES.txt : then when you svn merge, there will be no merge conflict, it will just work. That assumes you know, before commiting to trunk, that it will (or wont) be backported to 3x. The approach (and the cleanness of the merges) completley breaks down if you start out assuming a feature is targetting 4x, and then later decide to backport it. it will also break down in even more fun and confusing ways if/when we have our first 4.0 release and then someone pushes for having a 3.42 feature release after that (to push out some high value features to people not yet ready to upgrade to 4.0) because the changes legitimately need to show up in both the 3.42 and 4.1 release notes. I've tried to raise these concerns several times in the past and gotten virtually no response... http://markmail.org/message/s6zq4e7aomanxulp http://search.lucidimagination.com/search/document/9a9b1327fe281305/solr_changes_3_1_4_0 I really think that the 4.0 section of CHANGES should list *every* change on the trunk prior to the 4.0 release, even if it was backported to 3.1 or 3.3 -- because fundementally the "changes" are not neccessarily identicle. A bug fix that has been backported may be subtley different because of the differneces between the branches. I also (still) agree with Ryan about the "historic record" nature of CHANGES.txt not making sense anymore now that we have multiple feature release branches going at once... >> Can we delete everything past line 441 in: >> https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/CHANGES.txt >> and add a comment saying to look at: >> https://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x/lucene/CHANGES.txt +1 -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: managing CHANGES.txt?
On Wed, Jun 1, 2011 at 11:21 AM, Ryan McKinley wrote: > I know we have talked about this a few times, but not sure where we left off. > > My understanding was that if we change something in trunk and merge to > 3.x we *only* add it to the 3.x CHANGES. If it is only for 4.x it > gets added to the 4.x CHANGES. But it looks like we are actually > keeping the two versions in sync. Is this just extra work? > you just commit it to the version it was added. For example, if you are adding something to 3x and trunk, commit it to the 3x section of trunk's CHANGES.txt then when you svn merge, there will be no merge conflict, it will just work. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
managing CHANGES.txt?
I know we have talked about this a few times, but not sure where we left off. My understanding was that if we change something in trunk and merge to 3.x we *only* add it to the 3.x CHANGES. If it is only for 4.x it gets added to the 4.x CHANGES. But it looks like we are actually keeping the two versions in sync. Is this just extra work? I'm sure this has been discussed before, but can trunk changes only track changes in trunk and keep anything before that in the 3.x branch? Can we delete everything past line 441 in: https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/CHANGES.txt and add a comment saying to look at: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x/lucene/CHANGES.txt When trunk gets moved to branch_4x, the 3.x changes would get copied over (and presumably not changed anymore) thoughts? ryan - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
