lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: Changes Mess
Date Sun, 05 Dec 2010 06:03:43 GMT
I like this idea myself - it would encourage better JIRA summaries and 
reduce duplication.

It's easy to keep a mix of old and new too - keep the things that Grant 
mentions in CHANGES.txt (back compat migration, misc info), but you can 
also just export a text Changes from JIRA at release and add that (along 
with a link). Certainly nice to have a 'hard' copy.

The only thing I don't like is the loss of the current credit system - I 
like that better than the crawl through JIRA method. I think prominent 
credits are a good encouragement for new contributors.

Any comments on that?

- Mark

On 12/2/10 11:46 AM, Grant Ingersoll wrote:
> I think we should drop the item by item change list and instead focus on 3 things:
> 1. Prose describing the new features (see Tika's changes file for instance) and things
users should pay special attention to such as when they might need to re-index.
> 2. Calling out explicit compatibility breaks
> 3. A Pointer to full list of changes in JIRA.  Alternatively, I believe there is a way
in JIRA to export/generate a summary of all issues fixed.
> #1 can be done right before release simply by going through #3 and doing the appropriate
wordsmithing.  #2 should be tracked as it is found.
> It's kind of silly that we have all this duplication of effort built in, not too mention
having to track it across two branches.
> We do this over in Mahout and I think it works pretty well and reduces the duplication
quite a bit since everything is already in JIRA and JIRA produces nice summaries too.  It
also encourages people to track things better in JIRA.  #1 above also lends itself well as
the basis of press releases/blogs/etc.
> -Grant
> On Dec 1, 2010, at 11:54 AM, Michael McCandless wrote:
>> So, going forward...
>> When committing an issue that needs a changes entry, where are we
>> supposed to put it?
>> EG if it's a bug fix that we'll backport all the way to 2.9.x... where
>> does it go?
>> If it's a new feature/API that's going to 3.x and trunk... only in
>> 3.x's CHANGES?
>> Mike
>> On Wed, Dec 1, 2010 at 9:22 AM, Uwe Schindler<>  wrote:
>>> Hi all,
>>> when merging changes done in 2.9.4/3.0.3 with current 3.x and trunk I found
>>> out that 3.x changes differ immense between the trunk changes.txt and the
>>> 3.x changes.txt. Some entries are missing in the 3.x branch, but are
>>> available in trunk's 3.x part or other entries using new trunk class names
>>> are between 3.x changes in trunk.
>>> I copied over the 3.x branch CHANGES.txt over trunks 3.x section and
>>> attached a patch of this. What should we do? Its messy :( Most parts seem to
>>> be merge failures. We should go through all those diff'ed issues and check
>>> where they were really fixed (3.x or trunk) and move the entries
>>> accordingly. After that in the 3.x branch and in trunk's 3.x section of
>>> CHANGES.txt should be identical text!
>>> Uwe
>>> -----
>>> Uwe Schindler
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>> eMail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --------------------------
> Grant Ingersoll
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message