[1.35.0] Building the release?
I'm starting to test build release candidate files for 1.35.0. The 1.34.0 and 1.34.1 release candidates were build by hand, IIUC. There is a Python script to do that job (boost-root/tools/release/make_tarballs.py), but it is out of date. I'm starting to work on updating it. What does such a script have to do? * Export SVN branches/release with the correct line endings for POSIX and Windows. * Build the quickbook/boostbook docs. * Set various file permissions. * Build the actual .zip, .gz, .bz2, and .7z files. What else? Where do the beta.boost.org web pages come from? --Beman PS: In the future, I think we should start building release files nightly for the next release as soon as a release ships. That will speed the process of identifying problems.
Beman Dawes wrote:
What else? Where do the beta.boost.org web pages come from?
Which web pages specifically? All of them? The docs? Oh, and at some point we, RSN, need to make a new boost-root/readme|index.html page. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
For example, in 1.34.x there was a page boost-root/more/cpp_committee_meetings.html On the beta site, it has migrated to http://beta.boost.org/community/committee.html But even after running bjam in release-candidate-root/doc that page (and other, if not all, http://beta.boost.org pages) is missing. And let's not forget the home page itself. There is still a version in the root-directory, but it is the old design, not the beta.boost.org design. Furthermore, the release-candidate tree contains directories such as bin.v2 that shouldn't be in the release-candidate. I'm guessing that https://svn.boost.org/svn/boost/website/public_html/beta has to be exported, then merged with the directory tree that resulted from exporting https://svn.boost.org/svn/boost/branches/release and then running bjam. But I need specifics. Also, having two repositories that have to be exported and then merged seems confusing and error prone. Why hasn't the new https://svn.boost.org/svn/boost/website/public_html/beta material just been integrated into the trunk, and thus will flow into the release branch with everything else destined for the next release? I must be missing something.
Oh, and at some point we, RSN, need to make a new boost-root/readme|index.html page.
Yep! --Beman
Beman Dawes wrote:
That old index.html page needs to go away and be replaced with new content specific for the release.
Furthermore, the release-candidate tree contains directories such as bin.v2 that shouldn't be in the release-candidate.
That's the build tree. And it's definitely not to be included.
Nope :-) The point of the new web site is that the release *does not* contain the web site content. Hence there's no need to synchronize the web site with the release.
Yep... You are missing the part where the web site is not integrated into the release. So the only integration that needs to happen is building the library docs, if needed.
OK, some suggestions on content for that release page are welcome. Obviously at minimum having the usual release notes in it. But some intro text with a pointer to the getting started docs would also be a minimum requirement. What else? PS. I have some minor items to clean up on the new web site which I see about doing tonight. So we have to start working on making the site live (i.e. replace the existing site). Not sure what coordination is needed to get the DNS and live content working. I think I can take care of the web server related parts, but help from Doug might be required. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Are you saying that the root index.html pages for the release and the web site have different content?
Right.
How do users who need the web site content locally download it? Does the web site contain all the content of the release? Even if they aren't physically integrated, how are they logically integrated?
Something has to happen to keep the release and the web site in sync.
I've been assuming that it is the same process as in past releases. When the release is ready, the release manager copies it to the web server. Is there a writeup somewhere of this new scheme? I'm lost. --Beman
Beman Dawes wrote:
Are you saying that the root index.html pages for the release and the web site have different content?
Yes.
How do users who need the web site content locally download it?
They don't. A user should not need the web site content to use the release.
Does the web site contain all the content of the release? Even if they aren't physically integrated, how are they logically integrated?
Logically the docs for each release is available in the web site. In the docs section you can browse those docs for each release. For example for 1.34.1 <http://beta.boost.org/doc/libs/1_34_1>. Physically the web site has a copy of the ZIP archive for the release and unpacks and presents those docs dynamically.
Something has to happen to keep the release and the web site in sync.
Sure :-) But the goal was to minimize the connection in order to make updating the web site much easier, and to make the release process less work...
I've been assuming that it is the same process as in past releases. When the release is ready, the release manager copies it to the web server.
"Copy it to the web server" is still the essential step. But instead of copying a bunch of files you copy the ZIP archive and edit the web site to use "publish" it.
Is there a writeup somewhere of this new scheme? I'm lost.
Not yet, since I avoid writing docs for something I haven't actually done yet ;-) So here's the planned steps (reality may vary): * Create the release (docs, archive, whatever) * Upload the ZIP archive, boost_1_35_0.zip, to the server. Currently it would be to /home/grafik/www.boost.org/archives/live * Edit the beta web site content to show the new release. Some of the edits can happen even before the archive is uploaded... Edits: * Add new libraries to the library list <http://svn.boost.org/trac/boost/browser/website/public_html/beta/doc/libraries.xml>. * Edit the docs display to ensure that the docs for each library display correctly. This is the hardest step so far since there's some magic PHP code doing this <http://svn.boost.org/trac/boost/browser/website/public_html/beta/doc/display_libs.php>. * Add the release to the history <http://svn.boost.org/trac/boost/browser/website/public_html/beta/feed/history> and edit the downloads to make it the active release <http://svn.boost.org/trac/boost/browser/website/public_html/beta/feed/build.jam#L58>. Then rebuild the RSS feeds. The general procedure for this is documented at <http://beta.boost.org/development/website_updating.html#Feeds>. And as the last step, merge the changes from the beta site <http://svn.boost.org/trac/boost/browser/website/public_html/beta> to the live site <http://svn.boost.org/trac/boost/browser/website/public_html/live>. With the obvious testing in between to make sure that the content is correct in the beta site before pushing it to the live site ;-) Note, some of those edits above are what I need to work on now. And I should say that I'm always trying to make the editing as simple as possible so things may change as I work through the actual steps and figure out how to automate the work. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Sebastian Redl wrote:
You'll have to be more specific as to what you consider "the documentation part". Note the pages pointed to from <http://beta.boost.org/doc/libs> *are* the releases, literally. PS. Just noticed the links on those are to 1.33.1. Need to fix that :-\ -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
OK. That should work.
Forwarding to individual libs doesn't seem to be fully functional. On the live web site, www.boost.org/libs/filesystem pulls up the filesystem docs. But beta.boost.org/libs/filesystem gets a 404. It looks like it tries to do the redirection, but something misfires.
OK. These procedures need to be worked out in detail, and then tested before we go live.
Understood. Thanks for all your help on this. --Beman
On Jan 22, 2008, at 8:12 PM, Rene Rivera wrote:
There's probably some small amount of configuration we'll need to do on our end to prepare for the new site, e.g., if we want to keep beta.boost.org active but separate from (www\.?)boost.org. Let's coordinate this offline, because it's unlikely that I'll be checking the Boost list frequently enough this week or next to be a useful participant. - Doug
on Tue Jan 22 2008, Beman Dawes <bdawes-AT-acm.org> wrote:
Are we inserting any redirects so that peoples' links won't break for a while? -- Dave Abrahams Boost Consulting http://boost-consulting.com
On 01/02/2008, David Abrahams <dave@boost-consulting.com> wrote:
Yes, Rene did it a while ago. You can see the rewrite rules at: http://svn.boost.org/svn/boost/website/public_html/beta/.htaccess If you want to test it, you can try going to the old location, but on beta.boost.org: http://beta.boost.org/more/cpp_committee_meetings.html Daniel
on Fri Feb 01 2008, "Daniel James" <daniel_james-AT-fmail.co.uk> wrote:
Hmm, http://beta.boost.org/more/getting_started doesn't seem to go anywhere useful. -- Dave Abrahams Boost Consulting http://boost-consulting.com
participants (6)
-
Beman Dawes -
Daniel James -
David Abrahams -
Doug Gregor -
Rene Rivera -
Sebastian Redl