Skip to content

Instantly share code, notes, and snippets.

@totten
Forked from colemanw/gist:4f00dc8892e1ad449f81
Last active August 29, 2015 14:08
Show Gist options
  • Save totten/3d03927cb490a4faaf97 to your computer and use it in GitHub Desktop.
Save totten/3d03927cb490a4faaf97 to your computer and use it in GitHub Desktop.
// 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}
]
...
]
@colemanw
Copy link

Cool, this spec is shaping up nicely, thanks for thinking around the edge cases.

One question: When would we ever want the majorVersion to be different than the branchName? Seems to make everything easier if they are always exactly the same, and so far they always have been afaik.

@colemanw
Copy link

Another thought: what if we also include a datestamp for each release in the json? Seems like a generally useful thing to have, but my specific reason for including it is that you could compare the dates of security releases to find out if there is a more recent security release on a later majorVersion, which would mostly tell you if your older version is still secure (it wouldn't account for security issues that only affect later versions, but at least that means it errs on the side of caution). A fully comprehensive solution, if we want to go there, would be to also include an array of versions affected by a security release, like:

{
  "4.4": [
    {version: "4.4.0", date: "2013-01-02"},
    {version: "4.4.1", date: "2013-02-03"},
    {version: "4.4.2", date: "2013-03-04", security: true, affects: ["4.1", "4.2", "4.3", "4.4.0", "4.4.1"]}
  ]
  ...
}

@totten
Copy link
Author

totten commented Dec 13, 2014

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).

@totten
Copy link
Author

totten commented Dec 13, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment