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.
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12315147&styleName=Text&projectId=12310110&Create=Create
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<u...@thetaphi.de> 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
http://www.thetaphi.de
eMail: u...@thetaphi.de
---------------------------------------------------------------------
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
--------------------------
Grant Ingersoll
http://www.lucidimagination.com
---------------------------------------------------------------------
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
