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