On Wed, 2015-10-14 at 11:39 +0100, Daniel P. Berrange wrote: > On Wed, Oct 14, 2015 at 10:25:35AM +0100, Daniel P. Berrange wrote: > > On Wed, Oct 14, 2015 at 10:36:02AM +0200, Andrea Bolognani wrote: > > > The changes for releases earlier than 0.7.1 were mostly lumped > > > together as opposed to being tidly organized with one change per > > > line, like we have done from that point onwards. > > > > > > As a result, they look awful in the HTML version and don't work > > > too well in the plain text version either. > > > > > > Luckily, except for the very first releases, the information is > > > still very detailed, so it's enough to organize it properly. > > > --- > > > docs/news.html.in | 1232 +++++++++++++++++++++++++++++---------- > > > -------------- > > > 1 file changed, 677 insertions(+), 555 deletions(-) > > > > I wonder, do we really want the news.html file growing without > > bound. Might a better approach be to start a new news.html.in > > file in January of each year. Then we can just split up the > > current file one for year past year. > > Or rather, always put the current year's news into news.html.in > but at the start of each year, archive the previous year's news > into news-$LASTYEAR.html.in. That ways news.html.in always > points to current news. Would that apply to the plain text version as well? That would mean having an additional 14 NEWS-* files in the release tarball, with one more to be added in just a few months. Aside from that, I like the idea. But it's orthogonal to this series and should be done as a follow-up, once everything's already nice and tidy. Cheers. -- Andrea Bolognani Software Engineer - Virtualization Team -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list