: 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
On Thu, Jun 30, 2011 at 6:02 PM, Chris Hostetter
hossman_luc...@fucit.org 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
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:
On Tue, Jun 21, 2011 at 1:09 PM, Chris Hostetter
hossman_luc...@fucit.org 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,
@lucene.apache.org
Subject: Re: managing CHANGES.txt?
On Tue, Jun 21, 2011 at 1:09 PM, Chris Hostetter
hossman_luc...@fucit.org 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
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
On 6/21/2011 at 1:26 PM, Robert Muir wrote:
On Tue, Jun 21, 2011 at 1:23 PM, Steven A Rowe sar...@syr.edu 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,
On Tue, Jun 21, 2011 at 1:47 PM, Steven A Rowe sar...@syr.edu wrote:
On 6/21/2011 at 1:26 PM, Robert Muir wrote:
On Tue, Jun 21, 2011 at 1:23 PM, Steven A Rowe sar...@syr.edu wrote:
Is the CHANGES.txt policy you advocate (and police) written up in one
place? I'm sure you'd like to not have
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
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
On 6/21/2011 at 1:52 PM, Robert Muir wrote:
On Tue, Jun 21, 2011 at 1:47 PM, Steven A Rowe sar...@syr.edu wrote:
On 6/21/2011 at 1:26 PM, Robert Muir wrote:
On Tue, Jun 21, 2011 at 1:23 PM, Steven A Rowe sar...@syr.edu wrote:
Is the CHANGES.txt policy you advocate (and police) written up
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
: 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.
On Tue, Jun 21, 2011 at 2:47 PM, Chris Hostetter
hossman_luc...@fucit.org 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
On Fri, Jun 10, 2011 at 9:31 PM, Chris Hostetter
hossman_luc...@fucit.org 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
: 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,
On Thu, Jun 9, 2011 at 3:22 PM, Chris Hostetter
hossman_luc...@fucit.org 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
On Thu, Jun 9, 2011 at 4:44 PM, Chris Hostetter
hossman_luc...@fucit.org 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
: 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
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
On Wed, Jun 1, 2011 at 11:21 AM, Ryan McKinley ryan...@gmail.com 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
21 matches
Mail list logo
