gistfile1.js

// Currently going to latest.civicrm.org/stable.php outputs:
4.5.2

// Proposed new output (B)
[
  {version: "4.4.0"},
  {version: "4.4.1"},
  {version: "4.4.2", security: true}
  {version: "4.5.0"},
  {version: "4.5.1"},
  {version: "4.5.2", security: true}
  ...
]

// Proposed new layout (C)
[
  "4.4": [
    {version: "4.4.0"},
    {version: "4.4.1"},
    {version: "4.4.2", security: true}
  },
  "4.5":
    {version: "4.5.0"},
    {version: "4.5.1"},
    {version: "4.5.2", security: true}
  ]
  ...
]

Agree that it's a good convention for BranchNames to match MajorVersions - and we can usually speak of them interchangably. There are cases where they don't match (e.g. "master" vs "4.6" at time of writing) or where matching would be nonsensical (e.g. "master-civimail-abtest" is a long-running feature-branch). It's conceivable that we could change SCM software (svn/bzr/hg/etc) or SCM-conventions (git-flow,etc). Regardless of what happens to SCM, though, we would still speak about releases using MajorVersions and MinorVersions. From the perspective of a client deciding whether to upgrade, it only needs to understand version#s -- not SCM.

+1 for including the release-dates.

-1 for the comprehensive solution (for the moment). I think it would be nice to publish more detailed info about version#s and SAs, but processing that requires more work at every level (spec + publishing + consuming; upfront + ongoing). Publishing version#s and dates is a good bite-sized project (for the moment).

Let's move further discussion to https://issues.civicrm.org/jira/browse/CRM-13672 since gist doesn't support email notifications.