[1.45.0] release note are insufficient
I have translated the release notes of 1.45.0 into Japanese now(but, don't .qbk). https://sites.google.com/site/boostjp/document/version/1_45_0 In the work, I found the missing library in release note: - Polygon : rev.66403 - Property Tree : #4340 - Serialization : rev.65965, rev.66030, rev.66107, rev.66123 - Thread : #4727, #4531, #2330 -- Akira Takahashi Blog : http://d.hatena.ne.jp/faith_and_brave/
Akira Takahashi wrote:
I have translated the release notes of 1.45.0 into Japanese now(but, don't .qbk). https://sites.google.com/site/boostjp/document/version/1_45_0
In the work, I found the missing library in release note:
- Polygon : rev.66403
Changes in the Polygon library made it into the release somewhat by accident because I committed to the release branch thinking the release had already gone out. The changes consisted of bug fixes (primarily to arbitrary angle polygon resizing) and since release regressions were passing we choose not to revert the changes for the 1.45.0 release. We did, however, overlook updating the release notes to reflect the inclusion of the bug fixes. The bugs in question were never filed in trac (that I know of). It isn't clear to me that all changes to libraries need to be mentioned in the release notes. I have noted that there has already been some usage of Boost.Polygon in Japan. There was a presentation on Boost.Polygon usage in Japanese that I saw a couple months back. Regards, Luke
2010/11/23 Simonson, Lucanus J <lucanus.j.simonson@intel.com>:
We did, however, overlook updating the release notes to reflect the inclusion of the bug fixes. The bugs in question were never filed in trac (that I know of). It isn't clear to me that all changes to libraries need to be mentioned in the release notes.
Because I fail to understand contents of change of Polygon by commitment message or Trac, either, it indicated, but judgment of release notes is left to you.
I have noted that there has already been some usage of Boost.Polygon in Japan. There was a presentation on Boost.Polygon usage in Japanese that I saw a couple months back.
I am holding the Boost.StudyMeeting(japanese translation is "Boost.勉強会") irregularly. A participant is around 100 persons each time. There was a presentation of the usage which combined Boost.Polygon and OpenGL in December, last year. -- Akira Takahashi Blog : http://d.hatena.ne.jp/faith_and_brave/
Akira.T wrote:
2010/11/23 Simonson, Lucanus J <lucanus.j.simonson@intel.com>:
We did, however, overlook updating the release notes to reflect the inclusion of the bug fixes. The bugs in question were never filed in trac (that I know of). It isn't clear to me that all changes to libraries need to be mentioned in the release notes.
Because I fail to understand contents of change of Polygon by commitment message or Trac, either, it indicated, but judgment of release notes is left to you.
You would have had to look at all the commits to the trunk after the previous commit to the release branch to track down what changed between merges to the release branch. The detailed commit messages go to the trunk and the release branch gets "merge from trunk" or "syncing up with trunk" because it is bundling together many changes made to the trunk since the last time the branches were merged.
I have noted that there has already been some usage of Boost.Polygon in Japan. There was a presentation on Boost.Polygon usage in Japanese that I saw a couple months back.
I am holding the Boost.StudyMeeting(japanese translation is "Boost.勉強会") irregularly. A participant is around 100 persons each time. There was a presentation of the usage which combined Boost.Polygon and OpenGL in December, last year.
That was the one I saw. Regards, Luke
I have translated the release notes of 1.45.0 into Japanese now(but, don't .qbk). https://sites.google.com/site/boostjp/document/version/1_45_0
In the work, I found the missing library in release note:
- Property Tree : #4340 There are other bugfixes from PTree in the release too, but I don't feel
On 22.11.2010 16:20, Akira Takahashi wrote: the need to edit the release notes just because a few bugfixes went in. Should I? Sebastian
On 23 November 2010 08:15, Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
There are other bugfixes from PTree in the release too, but I don't feel the need to edit the release notes just because a few bugfixes went in. Should I?
Opinions vary. I originally felt that the release notes should reflect more significant changes. Bug fixes could be mentioned in individual library change logs (maybe adding links to the release notes). But a lot of people seem to want the release notes to include every bug fix. We could split the notes into 'major' and 'minor' changes, it's mainly due to inertia that they're organized the way they are. Anyway, we can add notes after the release if you wish. It's best to do it in one big push, as it currently causes the notes to appear in people's feed readers again. Daniel
Thomas Klimpel wrote:
But a lot of people seem to want the release notes to include every bug fix.
Don't do that, please.
-1 I want to know the complete list of changes. I'd be happy with a highlights section and a details section or with links to full lists for individual libraries in a summary type release notes page. I don't care if the details merely reference Trac issues, so long as the final state of those issues clearly identify the problem and the solution. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 11/23/2010 7:03 AM, Stewart, Robert wrote:
Thomas Klimpel wrote:
But a lot of people seem to want the release notes to include every bug fix.
Don't do that, please.
-1
I want to know the complete list of changes. I'd be happy with a highlights section and a details section or with links to full lists for individual libraries in a summary type release notes page. I don't care if the details merely reference Trac issues, so long as the final state of those issues clearly identify the problem and the solution.
The usual solution to this is to list major changes in the overall release notes (if any). And each library has it's own comprehensive changelog. For examples see Spirit, Wave, and Quickbook. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera wrote:
On 11/23/2010 7:03 AM, Stewart, Robert wrote:
I want to know the complete list of changes. I'd be happy with a highlights section and a details section or with links to full lists for individual libraries in a summary type release notes page. I don't care if the details merely reference Trac issues, so long as the final state of those issues clearly identify the problem and the solution.
The usual solution to this is to list major changes in the overall release notes (if any). And each library has it's own comprehensive changelog. For examples see Spirit, Wave, and Quickbook.
Yes. I appreciate those. I'd like to see that be official policy. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 11/23/2010 8:03 AM, Stewart, Robert wrote:
Thomas Klimpel wrote:
But a lot of people seem to want the release notes to include every bug fix.
Don't do that, please.
-1
I want to know the complete list of changes. <snip>
I would also like every library to provide a complete list of bugs fixed on the release notes page, if only to impress upon people that we are taking quality seriously, and that we pay attention to bugs in the tracker. See this comment on reddit: http://www.reddit.com/r/cpp/comments/e8z7t/boost_v145_released/c16ep9p Impressions do matter. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 11/23/2010 8:09 AM, Eric Niebler wrote:
On 11/23/2010 8:03 AM, Stewart, Robert wrote:
Thomas Klimpel wrote:
But a lot of people seem to want the release notes to include every bug fix. Don't do that, please. -1
I want to know the complete list of changes. <snip>
I would also like every library to provide a complete list of bugs fixed on the release notes page, if only to impress upon people that we are taking quality seriously, and that we pay attention to bugs in the tracker.
If the tracker is being used correctly, shouldn't the complete list of bug fixes be a query on the tracker for issues that were known in <version-1> and have been fixed in <version>? The main release notes could link to that query. I don't know if it needs to be one link per library though - some libraries might not have many fixes and clicking on a link just to see those would be tedious. A single link to a big list with issues categorized by library would suffice. -Matt
Someone wrote:
I want to know the complete list of changes.
I agree; it would be a useful thing. On Tue, Nov 23, 2010 at 08:33:58AM -0600, Matt Chambers wrote:
If the tracker is being used correctly, shouldn't the complete list of bug fixes be a query on the tracker for issues that were known in <version-1> and have been fixed in <version>?
Bugs are marked "fixed" as soon as the change is made in the trunk. However, the release procedure requires a second, manual step to merge the fix into the release branch. One problem I've repeatedly run into is that the second step is often missed. The result is that the issue tracker is much less useful than it could be. I think that would have to change before your idea (which otherwise appeals to me) would work. Regards, -Steve
On Nov 24, 2010, at 7:17 PM, Steve M. Robbins wrote:
Someone wrote:
I want to know the complete list of changes.
I agree; it would be a useful thing.
On Tue, Nov 23, 2010 at 08:33:58AM -0600, Matt Chambers wrote:
If the tracker is being used correctly, shouldn't the complete list of bug fixes be a query on the tracker for issues that were known in <version-1> and have been fixed in <version>?
Bugs are marked "fixed" as soon as the change is made in the trunk. However, the release procedure requires a second, manual step to merge the fix into the release branch.
One problem I've repeatedly run into is that the second step is often missed. The result is that the issue tracker is much less useful than it could be. I think that would have to change before your idea (which otherwise appeals to me) would work.
FWIW, what I do is that I add a note to the trac ticket when I fix the bug on the trunk, and then close the ticket when I merge to release. -- Marshall
Marshall Clow wrote:
On Nov 24, 2010, at 7:17 PM, Steve M. Robbins wrote:
Someone wrote:
I want to know the complete list of changes.
I agree; it would be a useful thing.
On Tue, Nov 23, 2010 at 08:33:58AM -0600, Matt Chambers wrote:
If the tracker is being used correctly, shouldn't the complete list of bug fixes be a query on the tracker for issues that were known in <version-1> and have been fixed in <version>?
Bugs are marked "fixed" as soon as the change is made in the trunk. However, the release procedure requires a second, manual step to merge the fix into the release branch.
One problem I've repeatedly run into is that the second step is often missed. The result is that the issue tracker is much less useful than it could be. I think that would have to change before your idea (which otherwise appeals to me) would work.
FWIW, what I do is that I add a note to the trac ticket when I fix the bug on the trunk, and then close the ticket when I merge to release.
Another alternative is to make release notes live in the same SVN tree as the code. Then, one will add a release note when fixing bug, and a subsequent merge to release branch will pick the release note as well. But the requires some tool support. - Volodya
participants (13)
-
Akira Takahashi -
Akira.T
-
Daniel James -
Eric Niebler -
Marshall Clow -
Matt Chambers -
Rene Rivera -
Sebastian Redl -
Simonson, Lucanus J -
Steve M. Robbins -
Stewart, Robert -
Thomas Klimpel -
Vladimir Prus