Checkout Tools
  • last updated 5 hours ago
Constraints: committers
Constraints: files
Constraints: dates
[On the staging-ng branch]

* BRANCH-README: New file.

Create branch of Subversion site for modernization project.

Remove unused old branch: site-ng.

This branch was created in 2015 and never used. Also it was branched

from the wrong level so it contained other branches. To be replaced by

a new "staging-ng" branch under subversion/site/.

* index.html

(#site-content): Use the correct trademark symbol.

* publish/index.html: Fix TM/(R) attributions on 'Apache Subversion'.
* publish/site-nav.html

Move 'binary packages' above 'source download' as a tiny recognition of

what I suppose are the most common needs.

* publish/site-nav.html: Add a link to 'Source Code' page in nav menu.
* publish/source-code.html

(#source-svn): un-linkify the ASF repo root, as not useful here.

* upcoming.part.html: Automatically regenerated
In 'staging': Tweak presentation of voting requirements.
In 'staging': Require only one +1 vote for non-LTS backports.
In 'Stabilizing and maintaining releases': merge clarifications from 'staging'.
Catch-up merge from 'publish' to 'staging'.
* docs/community-guide/releasing.part.html

(#release-stabilization-how-many-votes): Simplify.

* docs/community-guide/releasing.part.html

(#release-stabilization): Fix broken link.

* docs/community-guide/releasing.part.html: Use markup.
* docs/community-guide/releasing.part.html

(#release-stabilization): Mention and interactive mode.

* docs/community-guide/releasing.part.html

(#release-stabilization): Remove a paragraph.

"Vote if consensus fails" is the default; it needn't be spelled out.

* docs/community-guide/releasing.part.html

(#release-stabilization): Reorganization.

Add subsection headers.

Move paragraphs for flow.

Add some content (no new policies, of course).

Remove the "(for 1.7.2)" example. We don't need to spell out the

possibility of doing that.

Sync-merge from publish
    • ?
    • ?
  1. … 4 more files in changeset.
Publish some info on how we handle security issues.

Moved from:

* publish/docs/community-guide/issues.part.html

(#security): Point to information. Add sub-headings.

* publish/docs/community-guide/how-to-roll-releases-in-private.txt

New, extracted from the README.

Clarify LTS versus regular releases.

Suggested by: Thomas Singer <thomas.singer{_AT_}>

* download.html

Add a notice of latest LTS release after notice of latest regular release.

(#recommended-release): Change the title to "Latest regular release".

State the support period.

(#supported-releases): Change the title to "LTS releases".

State the support period.

Say "1.10 LTS" instead of just "1.10", and for 1.9, everywhere.

* index.html, news.html: remove incorrect anchors in links to download page in recent news items. Better with no anchor at all.
* site-nav.html (site-nav-menu): Remove currently unnecessary '?update=...' parameter from download link.
* upcoming.part.html: Automatically regenerated
Supported releases: Remove 'support period' column.

The info in it was simply wrong. Rather than correcting it, remove it as

correct and clearer details are already stated on the linked 'release planning' page.

Add recent CVEs to the list, and add my signature on their advisories.
    • ?
    • ?
Remove a step for updating the 'upcoming changes' branch for a new minor release.

Reverts r1864042, as it is now done a different way: "site: script

should automatically show changes for the latest stable branch".

* upcoming.part.html: Automatically regenerated
* publish/.message-ids.tsv: Automatically regenerated.