[release] files from previous releases (was: Re: [ Fusion ] Extra files in "release"?)
Joel de Guzman wrote:
Thanks for reporting! Seems a "release procedure issue" to me; the trunk has apparently been copied over an old release where those files were still present and needed. Those files can be deleted from the release branch (gone from trunk since February 09, last changes on Fusion in June 09). I just read that the release branch is about to freeze so posting to boost.devel for the Release Managers to join in. Also, there might be similar issues for other libraries.
Regards, Tobias
2010/1/13 Tobias Schwinger <tschwinger@isonews2.com>:
Seems a "release procedure issue" to me; the trunk has apparently been copied over an old release where those files were still present and needed.
There's no consensus on the best way to merge. A lot of developers seem to be set in their ways so it's up to the individual libraries to decide how they want to manage merge. Although, life would be a lot easier if we all followed the same process.
Those files can be deleted from the release branch (gone from trunk since February 09, last changes on Fusion in June 09).
The C++ files can be left until the next release as it's too late to remove them without good reason. The documentation should be fixed though, the last merge seem to have gone wrong. Daniel
Daniel James wrote:
Not good. Another issue: Boost.Functional.Forward / Factory are missing from the release branch. Fusion docs/examples reference them and, as Forward has been factored out of Fusion, it is required for the full functionality of older versions. Last release having been messed is something I object repeating. So I suggest we either roll back the Functional module to ~1 year ago (including the documentation, of course) or get the missing files in, docs repaired, and while we're at it we might as well remove the outdated files. So, may I please get all this stuff straightened out? Joel, in case I get a "go" from the Review Managers, please let me know about recent trunk changes on the docs which are to be kept out of the release, if any. Here are my apologies for missing the changes in the release procedure and holding up the schedule, now. Will be more attentive, from now on. I never really got a notification like "Copy / merge your libs to the Boost instance rooted in branches/release, now" (should there be one, maybe?). Regards, Tobias
Tobias Schwinger wrote:
I think that "release branch closes for all changes in a week" should have been a sufficient warning ;-) One important property of the current release process is that it's maintainers responsibility to put things on the release branch, and it can be done at whatever time is convenient for them. There's no process, either automatic or manual, to inspect all 90+ libraries, decide if some changes are good candidates for merge, and ping specific maintainers. - Volodya
Vladimir Prus wrote:
Hmmmyea, I meant by no means to blame the Release Managers for my infrequent reading of boost.devel, these days ;-). Else wouldn't have apologized for the trouble (not quoted in the reply). A notification on a low-frequency list (e.g. boost.announce) that it's "this time of the year, again" could've kept me from failing, though. Regards, Tobias
Tobias Schwinger wrote:
Given the relatively small number of library maintainers, wouldn't it be easy to just send all of them an email from time to time? It might only need consist of a link to the anouncements page. Robert Ramey
On 1/15/2010 12:38 PM, Robert Ramey wrote:
Even better: why not a "library maintainers" mailing list? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
Hmm, I am not sure that creating new mailing list specifically for such announcements is optimal way. If a maintainer is not regularly reading the mail list, he might just use the calendar: http://www.boost.org/community/index.html Either by: - adding that calendar to his Google Calendar setup - optionally, adding email notifications for events - checking the calendar automatically - adding RSS feed to that calendar to his feed reader Will that work? - Volodya
2010/1/14 Tobias Schwinger <tschwinger@isonews2.com>:
It's too late to add new libraries, they'll have to wait for the next release. Also, please contact the release managers first, there are few things we need to check and do for new libraries.
How disruptive will it be and what's actually broken? I understand that you want to clean things up but is there anything which really can't wait three months? The reason why we have frequent releases is so that there doesn't need to be a last minute rush to get features added. Daniel
Daniel James wrote:
)-:
Currently, the new interface is documented and implemented but can't do what an older version could for stuff that has been factored out is missing, now. The old interface is still there (those files I wanted to remove, at frist) but not what's documented and under test. So what can we do? Ordered by descending personal preference: A) * add dependencies (we can sustain any official advertisement until the next release, except for they're mentioned in Fusion docs) * remove outdated files (optional) * regenerate docs & check them, test locally, commit B) * ignore there is a problem, for now * regenerate docs (as reportedly broken) & check them, commit C) * keep headers as-is * partially roll back docs (non-trivial for QB macros/linkage) * get the old code back under test, maybe adjust after a test cycle * change some examples back to use the old code * regenerate docs & check them, test locally, commit
Well, just take your pick. Regards, Tobias
On 1/15/2010 1:37 PM, Tobias Schwinger wrote:
I can't parse this sentence. But it sounds like you're suggesting adding code to the release. I would be opposed to that.
What is being tested on the release branch? Are the tests failing there? If not, we just need to change the docs to reflect the actual code on the release branch. And that's it, IMO. I guess that's your option (B) above. -- Eric Niebler BoostPro Computing http://www.boostpro.com
2010/1/15 Eric Niebler <eric@boostpro.com>:
I've fixed the release documentation. There wasn't any difference between the trunk and release source so I just copied the generated documentation from trunk. So it should be pretty easy to update the documentation.
I agree. Daniel
Tobias Schwinger-2 wrote:
Boost.Functional.Forward / Factory have not yet released. IMO Fusion needs to update its documentation until these are released. Best, Vicente -- View this message in context: http://old.nabble.com/-release--files-from-previous-releases-%28was%3A-Re%3A... Sent from the Boost - Dev mailing list archive at Nabble.com.
Vicente Botet Escriba wrote:
They have been added to the trunk. With the old release procedure that would've included them into the next release. Won't bite me again.
IMO Fusion needs to update its documentation until these are released.
Actually, that's insufficient: The new version of that part of Fusion (which lacks what's implemented in Forward, compared to previous versions of Fusion) has already been merged to 'release' and is under test, right now. However, as freeze is freeze and any decent fix requires more changes than should happen at this point of the release, let's just call it a known bug. Regards, Tobias
participants (6)
-
Daniel James -
Eric Niebler -
Robert Ramey -
Tobias Schwinger -
Vicente Botet Escriba -
Vladimir Prus