I plan to do the actual release Sunday. Please make no further commits to branches/release. If there are any known showstoppers, please let me know right away. Thanks, --Beman
----- Original Message ----- From: "Beman Dawes" <bdawes@acm.org> To: "Boost Developers List" <boost@lists.boost.org> Sent: Friday, February 06, 2009 2:10 PM Subject: [boost] [1.38.0] branches/release frozen
I plan to do the actual release Sunday. Please make no further commits to branches/release.
If there are any known showstoppers, please let me know right away.
There are other libraries that have been modified that should add an item in this page even if the changes are minor and even more when there are semantic changes: * Any (semantic interface change) * Compatibility * CircularBuffer (warning removal) * ConceptCheck (warning removal) * Conversion (lexical_cast) * Format * Rational (warning removal) * Serialization * Spirit * System * Thread (behavior change) * Units * Utility * Wave Best, Vicente
2009/2/7 vicente.botet <vicente.botet@wanadoo.fr>:
There are other libraries that have been modified that should add an item in this page even if the changes are minor and even more when there are semantic changes: * Any (semantic interface change) * Compatibility * CircularBuffer (warning removal) * ConceptCheck (warning removal) * Conversion (lexical_cast) * Format * Rational (warning removal) * Serialization * Spirit * System * Thread (behavior change) * Units * Utility * Wave
Thanks for producing this list. If the changes to Utility are just the addition of the swap library, then it's already in the announcement. I don't think it's worth mentioning warning removals, if we go into that level of detail the interesting changes will get lost in the verbiage. Minor changes should be expected. That said, I don't think we have a clear policy on this. I'll take a look at the more significant changes later today. Daniel
On Sat, Feb 7, 2009 at 1:46 PM, Daniel James <daniel_james@fmail.co.uk> wrote:
I don't think it's worth mentioning warning removals, if we go into that level of detail the interesting changes will get lost in the verbiage.
Removal of warnings is important to me. I would upgrade to a new Boost release for this reason alone.
Minor changes should be expected. That said, I don't think we have a clear policy on this.
Yes, minor changes should be expected. But if I don't no about them, I don't get that extra info when debugging own code. /$
----- Original Message ----- From: "Daniel James" <daniel_james@fmail.co.uk> To: <boost@lists.boost.org> Sent: Saturday, February 07, 2009 1:46 PM Subject: Re: [boost] [1.38.0] branches/release frozen
2009/2/7 vicente.botet <vicente.botet@wanadoo.fr>:
There are other libraries that have been modified that should add an item in this page even if the changes are minor and even more when there are semantic changes: * Any (semantic interface change) * Compatibility * CircularBuffer (warning removal) * ConceptCheck (warning removal) * Conversion (lexical_cast) * Format * Rational (warning removal) * Serialization * Spirit * System * Thread (behavior change) * Units * Utility * Wave
Thanks for producing this list. If the changes to Utility are just the addition of the swap library, then it's already in the announcement.
Yes, maybe it is only that.
I don't think it's worth mentioning warning removals, if we go into that level of detail the interesting changes will get lost in the verbiage. Minor changes should be expected. That said, I don't think we have a clear policy on this.
I want only to help makeing a better release note. IMO it is interesting to see how the libraries evolve, so any detailled information is welcome. Maybe the minor changes must go in a specific section. Why not have a section for libraries with major changes, another for minor changes and another for libraries with only patches, documentation, warning or inspection removal modifications, ..
I'll take a look at the more significant changes later today. I have identifies Any and Thread as the libraries having interface change or behavior change.
Thanks, Vicente
vicente.botet wrote:
I don't think it's worth mentioning warning removals, if we go into that level of detail the interesting changes will get lost in the verbiage. Minor changes should be expected. That said, I don't think we have a clear policy on this.
I want only to help makeing a better release note. IMO it is interesting to see how the libraries evolve, so any detailled information is welcome. Maybe the minor changes must go in a specific section. Why not have a section for libraries with major changes, another for minor changes and another for libraries with only patches, documentation, warning or inspection removal modifications, ..
As a side note, some projects out there employ dual change list. The one that goes into the News page enlists only major changes and a link to the second one with more detailed description. The latter one is often compiled from particular tickets that were solved in this release. I'm not suggesting to do the same in this release, but this looks like a good practice to follow in future to me.
----- Original Message ----- From: "Andrey Semashev" <andrey.semashev@gmail.com> To: <boost@lists.boost.org> Sent: Saturday, February 07, 2009 2:56 PM Subject: Re: [boost] [1.38.0] branches/release frozen
vicente.botet wrote:
I don't think it's worth mentioning warning removals, if we go into that level of detail the interesting changes will get lost in the verbiage. Minor changes should be expected. That said, I don't think we have a clear policy on this.
I want only to help makeing a better release note. IMO it is interesting to see how the libraries evolve, so any detailled information is welcome. Maybe the minor changes must go in a specific section. Why not have a section for libraries with major changes, another for minor changes and another for libraries with only patches, documentation, warning or inspection removal modifications, ..
As a side note, some projects out there employ dual change list. The one that goes into the News page enlists only major changes and a link to the second one with more detailed description. The latter one is often compiled from particular tickets that were solved in this release.
I'm not suggesting to do the same in this release, but this looks like a good practice to follow in future to me.
I agree. Vicente
2009/2/7 Andrey Semashev <andrey.semashev@gmail.com>:
As a side note, some projects out there employ dual change list. The one that goes into the News page enlists only major changes and a link to the second one with more detailed description. The latter one is often compiled from particular tickets that were solved in this release.
I'm not suggesting to do the same in this release, but this looks like a good practice to follow in future to me.
It's a good idea, but we don't tend to create tickets for every issue. So this couldn't be done automatically from the tickets at the moment. We also have a culture of being very flexible about how libraries are maintained, these things are largely up to the library maintainers. Understandably, this often frustrates users who'd like a bit more consistency. Daniel
Daniel James wrote:
2009/2/7 Andrey Semashev <andrey.semashev@gmail.com>:
As a side note, some projects out there employ dual change list. The one that goes into the News page enlists only major changes and a link to the second one with more detailed description. The latter one is often compiled from particular tickets that were solved in this release.
I'm not suggesting to do the same in this release, but this looks like a good practice to follow in future to me.
It's a good idea, but we don't tend to create tickets for every issue. So this couldn't be done automatically from the tickets at the moment.
Yes, I agree. However, the list of tickets might go as a part of this list. Some libraries maintain their own change logs, and not every entry in these logs deserve to be mentioned on the News page. The detailed change log might accumulate the library-specific change logs in some way, and maybe this can be automated. The rest can be provided by hand, if needed.
We also have a culture of being very flexible about how libraries are maintained, these things are largely up to the library maintainers. Understandably, this often frustrates users who'd like a bit more consistency.
Well, if the maintainer doesn't document the changes he makes, there's little can be done anyway, isn't it?
on Sat Feb 07 2009, Daniel James <daniel_james-AT-fmail.co.uk> wrote:
2009/2/7 Andrey Semashev <andrey.semashev@gmail.com>:
As a side note, some projects out there employ dual change list. The one that goes into the News page enlists only major changes and a link to the second one with more detailed description. The latter one is often compiled from particular tickets that were solved in this release.
I'm not suggesting to do the same in this release, but this looks like a good practice to follow in future to me.
It's a good idea, but we don't tend to create tickets for every issue.
We should, though.
So this couldn't be done automatically from the tickets at the moment. We also have a culture of being very flexible about how libraries are maintained, these things are largely up to the library maintainers. Understandably, this often frustrates users who'd like a bit more consistency.
Yup. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
2009/2/6 Beman Dawes <bdawes@acm.org>:
I plan to do the actual release Sunday. Please make no further commits to branches/release.
If there are any known showstoppers, please let me know right away.
Last nights snapshot didn't include the documentation. Maybe a transitory problem? Daniel
On Sun, Feb 8, 2009 at 4:44 AM, Daniel James <daniel_james@fmail.co.uk> wrote:
2009/2/6 Beman Dawes <bdawes@acm.org>:
I plan to do the actual release Sunday. Please make no further commits to branches/release.
If there are any known showstoppers, please let me know right away.
Last nights snapshot didn't include the documentation. Maybe a transitory problem?
Looking at the log, it looks like for the docs zip download the ftp server closed down the connect prematurely. Hopefully that's just a transitory problem. I'm running a fresh snapshot now. --Beman
participants (6)
-
Andrey Semashev -
Beman Dawes -
Daniel James -
David Abrahams -
Henrik Sundberg -
vicente.botet