MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Remote_access",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "89": {
                "pageid": 89,
                "ns": 0,
                "title": "Release Matrix",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "{{Release Matrix}}\n[[CATEGORY: SprezzOS Releases]]"
                    }
                ]
            },
            "8": {
                "pageid": 8,
                "ns": 0,
                "title": "Release Model",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "At any time, SprezzOS can be uniquely defined by a snapshot at some previous time ''T'', plus an ordered list ''M'' of modifications since that time. The history of SprezzOS can be discretized by these ''M'', yielding a natural sequence ''T<sub>i</sub>''. Certain of these ''T<sub>i</sub>'' will mark the origin of a new branch (and thus a new ''M'' relative to ''T''), a ''release''.\n\nReleases, by reducing the amount of change undergone by the distribution in a given span of time, intend to ease the lives of external developers and system administrators. They are essentially external to the development process itself, and reflect this in their rule-oriented, somewhat arbitrary natures. Each active release has costs in terms of support and maintenance. As releases diverge further and further, those costs tend to increase. Tightly-clustered releases, meanwhile, add diminishing value. A newer release will typically exhibit greater:\n* hardware support\n* software features\n* reliability of existing software (bugfixes)\n* resource consumption\nwhile ABIs and other interfaces might have changed, at a maintenance cost for end users. Furthermore, a newer release might introduce new bugs, or eliminate necessary functionality. Ideally, every change to SprezzOS would result in a release (this is indeed possible for those building from source). Since releases have cost, however, the number of actively supported releases must be bound. Current development resources suggest that, in addition to trunk, one release (having fairly arbitrarily diverged) can be supported at any given time.\n\nReleases will thus be motivated by:\n* Features added since last release\n* Difficulty of adding those features, in isolation, to the last release\n* Necessity of lost/broken functionality from older releases\n* Time since last release\n\nSuccessive releases will have successive ''major numbers''. Official branching is only expected to be performed from the SprezzOS trunk. Each ''M'' applied to a release increments the ''minor number''. Whenever an ''M'' results in a new middle number for one of a release's kernels, that increments the ''middle number'' and resets the ''minor number''.\n\n==Release Matrix==\n{{:Release Matrix}}\n\n{{Handbook}}\n\n[[CATEGORY: SprezzOS Releases]]"
                    }
                ]
            }
        }
    }
}