MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "SDR_Satcom",
        "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": {
            "68": {
                "pageid": 68,
                "ns": 0,
                "title": "Reference Development Kit",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "__NOTOC__\n===About===\nThe Reference Development Kit is comprised of three individual hardware devices: the [[#Myriad-RF 1|Myriad-RF 1]], the [[#DE0-Nano Interface Board|DE0-Nano Interface Board]], and the [[#Zipper Interface Board#|Zipper Interface Board]]. The Myriad-RF 1 communicates with one of these two boards via the [[#RFDIO Interface|Radio Frequency Digital Input Output (RFDIO)]] interface.\n\n===Myriad-RF 1===\n[[File:Myriadrf1-1.jpg|100px|thumb|left]]\nThe [[Myriad-RF 1]] is a low cost universal radio development platform, based on the flexible, multi-standard [[LimeMicro:LMS6002D_Datasheet|LMS6002D transceiver]]. It enables developers to implement a wide variety of wireless communication applications. It is designed to be used with either the Digital Interface Board or the Zipper Interface Adapter.\n\n<div style=\"clear: both\"></div>\n===DE0-Nano Interface Board===\n[[File:DE0-Nano-Interface-Board-1.jpg|100px|thumb|left]]\nThe [[DE0-Nano Interface Board]] allows the Myriad-RF 1 to be connected to the [[DE0-Nano]] FPGA Development System, adding radio functionality to the system. It cannot be used with other FPGA development systems; for anything other than the DE0-Nano FPGA Development System, the [[#Zipper Interface Board|Zipper Interface Board]] should be used instead.\n\n<div style=\"clear: both\"></div>\n===Zipper Interface Board===\n[[File:Zipper-1.jpg|100px|thumb|left]]\nThe [[Zipper Interface Board]] allows the Myriad-RF 1 to be connected to any FPGA development system supporting the High-Speed Mezzanine Card (HSMC) or FPGA Mezzanine Card (FMC) standards, adding radio functionality to the system. The multi-platform compatibility of the Zipper Interface Board makes it suitable for a wide range of FPGA development systems from manufacturers including Altera and Xilinx.\n\n<div style=\"clear: both\"></div>\n===RFDIO Interface===\n[[File:RFDIO-Card-Connector-1.jpg|100px|thumb|left]]\nThe [[RFDIO]] Interface provides high-speed connectivity to FPGA-based carrier boards, including the [[#Digital Interface Board|Digital Interface Board]] and the [[#Zipper Interface Board#|Zipper Interface Board]] of the Reference Development Kit. It is based on the Hirose 0.5mm-pitch, 80-position surface-mount connector, and ensures interoperability between carrier boards and RF cards. The female connector is located on the motherboard, while the male connector is located on the daughterboard.\n\n<div style=\"clear: both\"></div>\n\n===See Also===\n* [[Myriad-RF 1]]\n* [[DE0-Nano Interface Board]]\n* [[Zipper Interface Board]]\n* [[RFDIO|RFDIO Interface]]\n* [https://myriadrf.org/projects/rdk/ Reference Development Kit Project Page]\n\n{{Community}}"
                    }
                ]
            },
            "465": {
                "pageid": 465,
                "ns": 0,
                "title": "ReleaseGuide",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "The release guide is a helpful page intended to manage the creation of releases for the LimeSuite project, although its notes should be applicable to other projects.\n\n==Version numbers==\n\nThe LimeSuite library has several similar version numbers to indicate project releases and other kinds of library compatibility. Mind them carefully. Here is a quick summary of these numbers and how they come into play. We will describe in more detail how to handle these numbers for making full and patch releases.\n\n===Project version number===\n\nThe project has a 3 digit version number in the form of '''year.month.patch'''.\n\n* The first digit is the current year as a two digit number (16, 17....)\n* The second digit is the current month as a two digit number (01, 02, 03, 04..11, 12)\n* The last digit is incremented for patch releases (0 - initial release, 1 - additional fixes, 2 - etc...)\n\n* The project version number is set by modifying '''VERSION_MAJOR.MINOR.PATCH''' in the top level Changelog.txt\n\n===API version number===\n\nThe API version number is very similar to the project version number and it is primarily used for clients of the library to be able to detect API differences using preprocessor defines.\nFor example if the project version number is 17.03.*, the library API will be defined as '''#define LIME_SUITE_API_VERSION 0x20170300'''.\nA client application can use preprocessor macros and simple hex shifts to detect the API version.\n\nTypically, the API version will not change during a major.minor release cycle.\nHowever, consider the following example: Suppose that the 17.03.1 release had an important fix,\nand by consequence modified how a particular API call operates under some conditions.\nTo enable a client application to detect this change, we might modify the API accordingly '''#define LIME_SUITE_API_VERSION 0x20170301'''.\nThe last two digits don't have to match the patch number,\nthey just need to be modified so that a client can detect that change in a meaningful way.\nThe usefulness of this this technique simply comes down to the specific circumstances. For example, a client application might have to maintain compatibility both for the current release and the yet-to-be-released stable branch that contains the API change.\n\n* The API version is set by editing '''LIME_SUITE_API_VERSION''' in '''src/VersionInfo.h'''\n\n===ABI version number===\n\nThe ABI version number represents the binary format of the library. The exact combination of functions, arguments, and classes form the ABI of the library. Typically, modifications of the headers of a library will cause ABI changes. If the ABI of the library is changed, its client applications must be recompiled or they will experience unknown failures like segmentation faults. On a unix system, the ABI is expressed as a suffix on the library. This allows multiple versions of the library to co-exist on one system.\n\nAlthough the ABI number is actually arbitrary, it should be used to represent the ABI of a version release, and changed when the ABI of the library actually changes.\nIn LimeSuite the ABI is set to '''major.minor-1''' by default. The only reason to change this, is if the ABI is broken for a patch release. This should be avoided in most cases.\n\n* The ABI version number can be modified by editing '''LIME_SUITE_SOVER''' in the top level CMakeLists.txt\n\n===Example unix library layout===\n\nHere is a demonstration for how these various version numbers come into play on a typical unix system\n\n<pre>\nls -al /usr/lib/libLimeSuite*\n\nlibLimeSuite.so -> libLimeSuite.so.17.03-1\nlibLimeSuite.so.17.03-1 -> libLimeSuite.so.17.03.0\nlibLimeSuite.so.17.03.0\n</pre>\n\n* libLimeSuite.so is a symlink to the current library, its used for development purposes as a conveniently named file to link against\n* libLimeSuite.so.17.03-1 is named after the ABI, other packaged applications look for this library by name. It symlinks to the latest installed version\n* libLimeSuite.so.17.03.0 is the actual library file and is named after the currently installed version of the library package\n\n==Git branching==\n\nThe LimeSuite repository has two important branches: stable and master.\n\n* The '''stable''' branch represents the latest release plus again additional fixes.\n* The '''master''' branch is is where new features and API/ABI changes occur.\n\n===The stable branch===\n\nThe stable branch gives users a way to track the most recent release plus any new fixes. Patch releases will be tagged from the stable branch.\n\n'''Here is the procedure for maintaining stable:'''\n\n* First a bug or typo is found. The fix should be applied to the stable branch (not master).\n* Edit the Changelog.txt with a brief description of the change. This makes it obvious what fixes have been addressed since the last release.\n* Push the commit(s) for the change and the Changelog to the stable branch.\n* Not its time to update the master branch. Merge stable into master and resolve any conflicts.\n\n'''Note:''' If this is the first commit after a release, make sure to increment the patch number 1) in the CMakeLists and 2) a new entry in the changelog.\n\n===The master branch===\n\nThe master branch contains new features and many times is subject to API and ABI changes. In general, the master branch should compile, though its possible that with new features come new bugs.\n\n'''Feature branches:''' When maintaining master, minor features and fixes for recent additions can go in at any time, but major features should be merged from a feature branch. Developing features on master could be disruptive to users. Its recommended to complete features on a dedicated \"feature\" branch and then to merge it into master when ready.\n\n'''Maintain the changelog:''' The master branch is a new major release in progress, and the changelog entry should contain brief descriptions. The entries should be pertinent to the next major release. For example: There's no need to mention fixes that only affect unreleased features. Pertinent entries might be:\n\n* API changes/breakages\n* major features/additions\n* removal/deprecations\n\n'''Note:''' If this is the first commit after a release, make sure to set a new version number 1) in the CMakeLists and 2) a new entry in the changelog. If this is the first API or ABI change after a release, also modify the relevant numbers in the CMakeLists/includes mentioned above.\n\n'''Note2:''' And make sure that the images are available for the latest release. These major.minor numbers are used to format the URL so images can be versioned with the software: http://downloads.myriadrf.org/project/limesuite/\n\n==Debian packaging==\n\nThe project contains a debian/ directory for building debian source packages which can be used to upload to PPA among other things.\n\n===Building locally===\n\nUse the git build package tool to create a set of debs or to test the build:\n\n<pre>\ngbp buildpackage --git-ignore-new --git-ignore-branch --git-export=WC --git-upstream-tree=HEAD --git-export-dir=$HOME/build-area\n</pre>\n\n===Uploading to a PPA===\n\nUploading a source package to the PPA involves\n\n# customizing the changelog with email and OS release,\n# running git build package to get a source package,\n# uploading the source package to the ppa with dput.\n\nI've created a helper script to automate the process. Feel free to pick it apart or change it.\n\n<pre>\n#this is an email registered with the PPA, pass it in with environment variables\nexport DEBFULLNAME=\"YOUR NAME\"\nexport DEBEMAIL=\"YOUR-EMAIL@gmail.com\"\n\n#run the PPA helper, specify the OS release (xenial)\n#The branch option will automatically used the latest release on that branch or\n#make a special version that is the latest release + number of commits since\nppa_helper --source=/path/to/LimeSuite --branch=stable --series=xenial --suffix=myriadrf1 --upload=ppa:myriadrf/drivers\n</pre>\n\n===Maintaining debian/===\n\nThe debian/ directory contains a few files that mirror the version numbers found in the Changelog.txt.  When making a new release the process is:\n\n* '''control''' - find and replace the version numbers for the current major release\n* '''changelog''' - add a new entry for every major/minor and patch release\n* '''liblimesuite[version]-1.install''' - rename to match current library ABI\n\n==Making a release==\n\nMaking a release is a checklist of tasks to get all of the numbers right and to create a git tag:\n\n===Update numbers and dates===\n\nIs this a patch release?\n<pre>\ngit checkout stable\n</pre>\n\nIs this a major/minor release?\n<pre>\ngit checkout stable\ngit pull origin master #master becomes the new stable\n</pre>\n\n# Edit Changelog.txt, but the current date of the release and double check the version number\n# Major release or ABI changes? update src/VersionInfo.h and debian/control and liblimesuite[version]-1.install files\n# Make a new entry in debian/changelog to match\n# Finally commit the changes and push to stable\n\n===Make the git tag===\n\nAfter making the commit, make the tag to match the current version Follow this format:\n\n<pre>\ngit tag -a v17.03.0 -m \"Lime Suite v17.03.0\"\ngit push origin v17.03.0 #make it public\n</pre>\n\n===Update master===\n\nAlways update the master branch to include the latest release information. No matter if this is a patch or major/minor release:\n\n<pre>\ngit checkout master\ngit pull . stable\ngit push origin master #resolve any conflicts\n</pre>"
                    }
                ]
            }
        }
    }
}