Re: managing CHANGES.txt?

2011-06-30 Thread Mark Miller

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?

2011-06-30 Thread Robert Muir
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?

2011-06-30 Thread Chris Hostetter

: 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?

2011-06-21 Thread Robert Muir
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?

2011-06-21 Thread Chris Hostetter

: > 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?

2011-06-21 Thread Mark Miller
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?

2011-06-21 Thread Steven A Rowe
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?

2011-06-21 Thread Steven A Rowe
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?

2011-06-21 Thread Mark Miller

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?

2011-06-21 Thread Robert Muir
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?

2011-06-21 Thread Steven A Rowe
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?

2011-06-21 Thread Robert Muir
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?

2011-06-21 Thread Steven A Rowe
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?

2011-06-21 Thread Robert Muir
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?

2011-06-10 Thread Robert Muir
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?

2011-06-09 Thread Ryan McKinley
>>
>> : 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?

2011-06-09 Thread Robert Muir
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?

2011-06-09 Thread Chris Hostetter

: > 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?

2011-06-09 Thread Robert Muir
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?

2011-06-09 Thread Chris Hostetter

: 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?

2011-06-01 Thread Robert Muir
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