On 12 July 2013 18:49, Rob Weir <robw...@apache.org> wrote:

> In the past we drafted release notes on the wiki, and then moved them
> to a location on the website.  I'd like to challenge our thinking on
> this.
>
> Wouldn't it be useful to keep the release notes as a "live" document
> on the wiki, so we can easily update it with additional information on
> known issues as they are found, especially after release?
>

I see your point, however I disagree.

I think the release doc. for 4.0 is part of the release and should be
frozen in svn like all other release artifacts. This is done by having it
as a static web page.

We can then have a "latest information", which are live in wiki.


>
> Remember, even if the issue is not caused by AOO code, a new upgrade
> to a dependent operating system or other 3rd party application can
> cause new issues to appear at any time.  So keeping  the release notes
> updated is important.
>

This issue is highly caused by AOO code, remember the release code is
tested with a given set of third party libraries and given versions of the
operating systems.

Release notes reflect the environment tested for the 4.0 release,
everything that comes later should either be kept in a separate document or
postponed to a new release.


>
> Do we lose anything if we do this?  For example, is there a concern
> that the wiki can not handle the load?
>

Wiki can handle the load (it must because a lot of people will search for
info).

Yes we loose trackability. Release notes is in svn (in my opinion).
Remember in wiki anybody can change, so if person X test AOO on platform Y
should he/she  then just update the release documentation, I hope not.

But again, your idea of a live document is good, I just see it as a second
document (similar to what a lot of companies does).

rgds
jan I.


>
> -Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Reply via email to