Re: Release Note Changes

On 11/30/07, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>
>
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
>
> > If people understand there aren't 13 performance improvements there are
> > at *least* 19+ that is a positive message to help people decide to
> > upgrade.
>
> Frankly I think the release notes are already too long. People who judge a
> release by counting the number of items in the release notes are not worth
> appeasing. Including every individual lock removed or code path optimized
> will
> only obscure the important points on which people should be judging the
> relevance of the release to them. Things like smoothing checkpoint i/o
> which
> could be removing a show-stopper problem for them.
>
> If they're mentioned at all a single release note bullet point saying
> "Many
> optimizations and concurrency improvements in areas such as transaction
> start
> and finish, checkpoint start, record visibility checking, merge join
> plans,
> ..." would suffice.
>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
> Ask me about EnterpriseDB's 24x7 Postgres support!
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

i agree that release notes should not be too long, but may be there should
be (if there isn't one already) something like a "change log" where people
can find out all the changes done from the previous release, if they are
intrested ?

--
Usama Munir Dar http://linkedin.com/in/usamadar
Consultant Architect
Cell:+92 321 5020666
Skype: usamadar