[jira] Resolved: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

other issue for making Changes.html visible also to users for closed releases. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > >

[jira] Updated: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

[ https://issues.apache.org/jira/browse/LUCENE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen updated LUCENE-1157: Priority: Minor (was: Major) > Formatable changes log (CHANGES.txt is easy to edit but not

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

atch, lucene-1157-take3.patch, > lucene-1157.patch > > > Background in http://www.nabble.com/formatable-changes-log-tt15078749.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

for some improvements to the Changes.html formatting, at LUCENE-1256. When you get a chance, would you please take a look? > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

nto an existing releases. "Release To Do" can be extended with the required steps for fixing/updating a release branch. Being a rare practice this might be enough...? > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to &g

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

view for releases going forward - contains changes only up to the release. # Per-release view for previous releases - contains changes only up to the release. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

pache.org/viewvc/lucene/java/branches/lucene_2_3/Changes.html?view=co But then future changes to the branch are likely to forget updating this file... Steven, what do you think of this? > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

oper Resources page now works! Doron, I noticed that when you initially committed this, you added an entry to CHANGES.txt, in the "Documentation" section, but it is no longer there. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to >

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

lucene-1157-take3.patch, > lucene-1157.patch > > > Background in http://www.nabble.com/formatable-changes-log-tt15078749.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

won't be branched on every release) > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > > Key: LUCENE-1157 >

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

d, either. Michael B., do you know what's going on here? You appear to be the deleter. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > -

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

and developer-resources seems the right place. But developer-resuorces.xml was deleted from svn in r611094 http://svn.apache.org/viewvc?view=rev&revision=611094 I think it was deleted by mistake? > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read b

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

tifact/changes/Changes.html > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > > Key: LUCENE-1157 >

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

ke a temporary work space, that might be erased during builds {quote} Yup, that's exactly what it is. I've updated Lucene-trunk build to grab trunk/build/docs/changes/* at the end of the build and save them as artifacts. > Formatable changes log (CHANGES.txt is easy to edit but n

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

quot;changes" an ok name for an "artifact" directory? > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > >

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

e of the build "artifacts" (just like the tar.gz files are saved). Grant can add this file to the artifacts list in the Hudson configuration screen if you want this done. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to >

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

http://hudson.zones.apache.org/hudson/job/Lucene-trunk/ws/trunk/build/docs/changes/Changes.html] > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > >

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

sn't sure... Ok I'll rename the directory and then we'll see. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > >

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

/changes/}} is unlinkable-to, because that directory is dedicated to the Hudson Changes page. Fixing this may be as simple as changing the name of the target directory, maybe to {{official-changes/}} or something like that. > Formatable changes log (CHANGES.txt is easy to edit but not so frien

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

cene-trunk/trunk/build/docs/changes {noformat} What's the trick to link/browse the files there? > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

docs. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > > Key: LUCENE-1157 > URL: https://issues.

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

arch engines, tweak robots.txt or add the directive. nofollow should affect ranking, but possibly not existence, in the index. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lu

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

d be moved to a new JIRA issue? > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > > Key: LUCENE-1157 >

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

wiki/Nofollow#Interpretation_by_the_individual_search_engines will help with some search engines. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lu

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

htly docs rel=nofollow? > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > > Key: LUCENE-1157 >

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

(for 2.3) > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > > Key: LUCENE-1157 > URL: https://is

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

w of CHANGES.txt in the developer documentation, I think there should be a static HTML view of CHANGES.txt produced with every release; this per-release HTML view should be available from the *product* documentation for the corresponding release. > Formatable changes log (CHANGES.txt is easy to e

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

generated by the nightly build on hudson, the same as seems to be done for the javadocs links? > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > ---

Re: [jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

n't fully follow. Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users) - Key: LUCENE-1157 URL: https://issues.apache.o

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

cs to the public website, the motivation for which I don't fully follow. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > >

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

Doug? I ask because I think a case could be made for providing a window for *users* onto the nature of the changes that will be in the next release. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to >

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

ity, which is wrong. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > > Key: LUCENE-1157 > URL:

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

hanges is more adequate?) > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > > Key: LUCENE-1157 >

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

the build process generating this file. I will commit shortly this patch when 'nightly' target generates the html file under build/docs/changaes. >From there we can copy it to the site. (more details later). > Formatable changes log (CHANGES.txt is easy to edit but not so friendly t

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

dson server. They are not copied to people. We could just make them an artifact that gets stored by Hudson. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lu

[jira] Issue Comment Edited: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

like: http://lucene.apache.org/docs/changes/changes2html.pl The perl script would than need to have a hard coded path to CHANGES.txt. It doesn't take the script long to execute, so this is feasible if traffic is low enough, and I'm guessing that this is so. > Formatable changes log (CHANGES.

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

l.pl The perl script would than need to have a hard coded path to CHANGES.txt. It doesn't take the script long to execute, so this is feasible if traffic is low enough, and I'm guessing that this is so. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

I can add an scp from the nightly build if you just tell me where the files exist relative to the lucene trunk (i.e. build/...) and where you want me to put them on the website. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

.. we can print a warning at the end of build if CHANGES.txt contains this BOMs. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - >

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

them to the nightly site is modified to also invoke "ant changes-to-html" and copy that too. Looking at nightly.sh it is not clear how to proceed b/c all the scp's are commented out (probably because Hudson now does this?) Thanks, Doron > Formatable changes log (CHANGES.

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

revert this and continue tomorrow. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > > Key: LUCENE-1157 >

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

like to put BOMs at the beginnings of UTF-8 encoded files. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > >

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

e site by Grant's scripts. I'll go on with this tomorrow. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > >

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

cene-java/HowToUpdateTheWebsite , anything checked into trunk/docs/ will be automatically mirrored to the live website by a cron job running under Grant's account. So, wouldn't it work to have Changes.html (and the stylesheets too) live in trunk/docs/ ? > Formatable changes log (CHANG

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

it now. Ideas? > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > > Key: LUCENE-1157 > URL: https

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

lucene-1157-take3.patch, > lucene-1157.patch > > > Background in http://www.nabble.com/formatable-changes-log-tt15078749.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --

Re: formatable changes log

I switched to maintaining the CHANGES file in YAML format for the solr-ruby library: There is even a unit test to make sure it at least parses properly:

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

e of presentation... > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > > Key: LUCENE-1157 > URL: htt

[jira] Updated: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

. > Formatable changes log (CHANGES.txt is easy to edit but not so friendly to > read by Lucene users) > - > > Key: LUCENE-1157 > URL: https://issu

[jira] Commented: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

ByTagName("ol")[i].style.display = "none"; } Not very clean, but I don't know a better solution for now. > Formatable changes log (CHANGES.txt is easy to edit b

RE: formatable changes log

On 01/26/2008 at 3:00 PM, Steven A Rowe wrote: > On 01/26/2008 at 2:26 PM, Doron Cohen wrote: > > On Jan 26, 2008 6:32 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote: > > > On 01/26/2008 at 8:07 AM, Grant Ingersoll wrote: > > > > On Jan 25, 2008, at 11:36 PM, Steven A Rowe wrote: > > > > > Here's the

[jira] Updated: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

om of the script; * now escaping HTML metachars '<', '>' and '&' in the output; and * reformatted to approximate Lucene's coding convention. This patch also includes an updated Changes.html. > Formatable changes log (CHANGES.txt is easy t

RE: formatable changes log

Hi Doron, On 01/26/2008 at 2:26 PM, Doron Cohen wrote: > On Jan 26, 2008 6:32 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote: > > On 01/26/2008 at 8:07 AM, Grant Ingersoll wrote: > > > On Jan 25, 2008, at 11:36 PM, Steven A Rowe wrote: > > > > Here's the Perl script I wrote to produce the above: > >

Re: formatable changes log

On Jan 26, 2008 6:32 PM, Steven A Rowe <[EMAIL PROTECTED]> wrote: > On 01/26/2008 at 8:07 AM, Grant Ingersoll wrote: > > On Jan 25, 2008, at 11:36 PM, Steven A Rowe wrote: > > > Here's the Perl script I wrote to produce the above: > > > > > >

[jira] Updated: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

http://www.nabble.com/formatable-changes-log-tt15078749.html). Changes: - new target "changes-to-html" in common-build generates Changes.html if CHANGES.txt was modified. - compile-core depends on this target. - two stylesheets in Changes.html - fancy and simple - something to start with. - only sh

Re: formatable changes log

On Jan 26, 2008, at 11:32 AM, Steven A Rowe wrote: On 01/26/2008 at 8:07 AM, Grant Ingersoll wrote: On Jan 25, 2008, at 11:36 PM, Steven A Rowe wrote: Here's the Perl script I wrote to produce the above: If we choose this, can you don

RE: formatable changes log

On 01/26/2008 at 8:07 AM, Grant Ingersoll wrote: > On Jan 25, 2008, at 11:36 PM, Steven A Rowe wrote: > > Here's the Perl script I wrote to produce the above: > > > > > > If we choose this, can you donate it? Yes, I can donate it. I put th

Re: formatable changes log

On Jan 25, 2008, at 11:36 PM, Steven A Rowe wrote: On 01/25/2008 at 2:05 PM, Chris Hostetter wrote: As it is becoming hard to browse/navigate CHANGES.txt, how about maintaining it in a simple HTML file? personally, i'm a fan of simple, plain text files for the CHANGES.txt ... easy to edit, e

Re: formatable changes log

On Jan 26, 2008, at 5:05 AM, Michael McCandless wrote: Steven A Rowe wrote: However, I noticed a problem: in CHANGES.txt under the 2.3.0 release in the "Bug fixes" section, there is a gap in the sequence: Argh! Yet more evidence that I cannot count :) This is the 2nd time I've done th

Re: formatable changes log

On Jan 26, 2008 6:36 AM, Steven A Rowe <[EMAIL PROTECTED]> wrote: > On 01/25/2008 at 2:05 PM, Chris Hostetter wrote: > > > As it is becoming hard to browse/navigate CHANGES.txt, how about > > > maintaining it in a simple HTML file? > > > > personally, i'm a fan of simple, plain text files for the

[jira] Created: (LUCENE-1157) Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users)

Formatable changes log (CHANGES.txt is easy to edit but not so friendly to read by Lucene users) - Key: LUCENE-1157 URL: https://issues.apache.org/jira/browse/LUCENE

Re: formatable changes log

Steven A Rowe wrote: However, I noticed a problem: in CHANGES.txt under the 2.3.0 release in the "Bug fixes" section, there is a gap in the sequence: Argh! Yet more evidence that I cannot count :) This is the 2nd time I've done that! But my script only notices that it's a numbered lis

RE: formatable changes log

On 01/25/2008 at 2:05 PM, Chris Hostetter wrote: > > As it is becoming hard to browse/navigate CHANGES.txt, how about > > maintaining it in a simple HTML file? > > personally, i'm a fan of simple, plain text files for the > CHANGES.txt ... easy to edit, easy to read. I don't know about easy to re

Re: formatable changes log

: - Need to define all developers/committers in front and assign each an ID, : and use this ID when referring to them. I guess we can ignore this practice ... : Person2). And BTW, AFAICT for now it does not support that P1 via P2 concept : (though that can be requested as a new feature).

Re: formatable changes log

On Jan 26, 2008 2:28 AM, Doron Cohen <[EMAIL PROTECTED]> wrote: > and with a very long file the ability to fold sections is missing > Actually the pdf version gives folding and so easier navigation.

Re: formatable changes log

On Jan 25, 2008 1:28 PM, Doron Cohen <[EMAIL PROTECTED]> wrote: > I'll check it, thanks Michael. > > On Jan 25, 2008 3:03 AM, Michael Busch <[EMAIL PROTECTED]> wrote: > > > Forrest has a plugin called projectInfo that can generate a list of > > changes and an RSS feed from a status.xml file: > > >

Re: formatable changes log

On Jan 25, 2008 9:05 PM, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > : As it is becoming hard to browse/navigate CHANGES.txt, how about > maintaining > : it in a simple HTML file? > > personally, i'm a fan of simple, plain text files for the CHANGES.txt ... > easy to edit, easy to read. I agr

Re: formatable changes log

: As it is becoming hard to browse/navigate CHANGES.txt, how about maintaining : it in a simple HTML file? personally, i'm a fan of simple, plain text files for the CHANGES.txt ... easy to edit, easy to read. that said: if people want to start using a more structured changelog file (xml/html/w

Re: formatable changes log

Doron Cohen wrote: As it is becoming hard to browse/navigate CHANGES.txt, how about maintaining it in a simple HTML file? Requirements are: - fancier formatting where adequate. - collapse/expand by release/subject - easy to maintain... Here is an example, containing the current (new) trunk and

Re: formatable changes log

I'll check it, thanks Michael. On Jan 25, 2008 3:03 AM, Michael Busch <[EMAIL PROTECTED]> wrote: > Forrest has a plugin called projectInfo that can generate a list of > changes and an RSS feed from a status.xml file: > > > http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugi

Re: formatable changes log

+1 I think readability/visibility of the CHANGES, both in CHANGES.txt and also in release announcements, news items, is important for "enticing" people to upgrade... Mike Doron Cohen wrote: As it is becoming hard to browse/navigate CHANGES.txt, how about maintaining it in a simple HTM

Re: formatable changes log

Forrest has a plugin called projectInfo that can generate a list of changes and an RSS feed from a status.xml file: http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.input.projectInfo/index.html Maybe we should use that? -Michael Doron Cohen wrote: > As it is becoming

formatable changes log

As it is becoming hard to browse/navigate CHANGES.txt, how about maintaining it in a simple HTML file? Requirements are: - fancier formatting where adequate. - collapse/expand by release/subject - easy to maintain... Here is an example, containing the current (new) trunk and 2.3.0 - http://people