{
    "info": {
        "author": "Manuel Bua",
        "author_email": "manuel.bua[at]gmail.com",
        "bugtrack_url": null,
        "classifiers": [
            "Development Status :: 4 - Beta",
            "License :: OSI Approved :: Apache Software License",
            "Programming Language :: Python :: 2.7",
            "Topic :: Software Development :: Version Control"
        ],
        "description": "|PyPi version| |PyPi downloads| |Project Stats| |Flattr this git repo|\n\nWhat is it?\n-----------\n\nA very simple, lightweight, tag-based version string manager for git,\nwritten in Python.\n\nIt generates version strings by using Python-based formatting rules\ncoupled with repository information, augmented by user-defined data.\n\nIt supports up to four different version number operands and optional\npre-release version information, in the format\n``[v]MAJOR.MINOR.PATCH[.REVISION][-PRE-RELEASE-METADATA]``, making to\nadopt versioning schemes such as `Semantic\nVersioning <https://semver.org>`__ a breeze.\n\nOptionally, it also keeps your project's version information blobs\nautomagically updated via custom templates.\n\nSample output (this repository):\n\n::\n\n    Most recent tag: v0.3.0-RC1\n    (NEXT defined as: 0.3.0)\n    Using pre-release metadata: RC1\n    Current build ID: 1d170e7f42817d0f277c52ad686b24ac69b353d4\n    Current version: v0.3.0-RC1.47+1d170e7 => v0.3.0\n\nInstallation\n------------\n\nPlease read the simple *Installation instructions* in the\n`INSTALL.md <https://github.com/manuelbua/gitver/blob/master/INSTALL.md>`__\nfile, you can install either via ``pip`` or by cloning this repository.\n\n*NOTE the **badges** present at the top of these pages (version and\ndownloads) refers to the latest stable packages uploaded to PyPI:\ncloning this repository will checkout the version i'm currently working\non and may not reflect the same version.*\n\nHelps in version string management\n----------------------------------\n\nCoupled with `git\nhooks <http://git-scm.com/book/en/Customizing-Git-Git-Hooks>`__,\n``gitver`` version blob templates helps to keep your own project updated\nwith its version information, performing simple template-based\nsubstitution automatically at *post-commit* time, for example.\n\nWhy?\n----\n\nI'm working on a project that requires precise version string tracking\nand synchronization between a server and its different clients, so an\nautomatic mechanism is needed.\n\nFurthermore, i want the version string and/or other useful information\nto be **embedded** in the application code automatically, \"compiled-in\"\nso to speak, without me having to remember to do it manually each time.\n\nRepository pre-requisites\n-------------------------\n\n``gitver`` expects your tags to be **annotated** and be in this format:\n\n::\n\n    [v]MAJOR.MINOR.PATCH[.REVISION][-PRE-RELEASE-METADATA]\n\nText in ``[`` square brackets ``]`` is optional, so these example tags\nare all valid for use with ``gitver``:\n\n::\n\n    v0.0.1\n    0.0.1-RC0\n    v0.0.1-RC2\n\nNote that, at this time, ``gitver`` will **not** skip unsupported tags\nduring its processing, so whenever it encounter such malformed tags\n(i.e. \"this-is-my-tag\") it will just error out something like this:\n\n::\n\n    ERROR: Couldn't retrieve version information from tag \"my-other-tag\".\n    gitver expects tags to be in the format [v]X.Y.Z[.REVISION][-PRE-RELEASE-METADATA]\n\nHowever, since ``gitver`` will only search for annotated tags, you could\nsafely use *unannotated tags* for any other need.\n\nWorkflow\n--------\n\nYour workflow shouldn't change much from what you are used to, but\nbefore using it, please review the \"Repository pre-requisites\" section\nabove and ensure your tags are not already being used for some other\npurpose.\n\n*Note that ``gitver`` will **never** tag, commit or interact in\nwrite-mode with your repository in any way, ever!*\n\nThe following is a workflow exemplification of using *gitver* to manage\nversion strings for your project, given it has already been setup:\n\n-  you are working on your repository, now you are ready to promote the\n   current version to the next release\n-  create a release tag, ``git tag -a v0.0.2 -m 'Bump version'``\n-  defines your NEXT version, the one you are going to work *towards* to\n   by running ``gitver next 0.0.3``\n-  run ``gitver`` and check everything is fine\n-  **OPTIONAL** preview or update your project's version information\n   templates by running ``gitver preview <template name>`` or\n   ``gitver update <template name>``, then rebuild the project to\n   reflect version changes\n-  any other manual house-keeping in-between releases can be performed\n   now\n-  now you are working towards the NEXT release, repeat when release\n   time has came again\n\nHow does it work?\n-----------------\n\nBy reading your last reachable **annotated** tag, it will generate\ncustomly-formatted version strings, distinguishing automatically between\n*stable* and *development* builds, depending on the number of commits\nfrom that last tag (the *commit count*).\n\nIt will also apply tag-based or configuration file-based pre-release\nmetadata in development builds, giving you fine-grained control on how\nthe final version string will be composed.\n\nConfig file\n-----------\n\n``gitver`` uses a per-repository, JSON-based configuration file.\n\nThe default configuration file gets created automatically in\n``.gitver/config`` and it contains the following tweakable settings:\n\n::\n\n    {\n        # automatically generated configuration file\n        #\n        # These defaults implement Semantic Versioning as described in the latest\n        # available documentation at http://semver.org/spec/v2.0.0.html\n\n        # by default, terminal output is NOT colorized for compatibility with older\n        # terminal emulators: you may enable this if you like a more modern look\n        \"use_terminal_colors\": false,\n\n        # prevent gitver from storing any information in its configuration directory\n        # if the .gitignore file doesn't exclude it from the repository\n        \"safe_mode\": true,\n\n        # default pre-release metadata when commit count > 0 AND\n        # no NEXT has been defined\n        \"default_meta_pr_in_next_no_next\": \"NEXT\",\n\n        # default pre-release metadata when commit count > 0\n        \"default_meta_pr_in_next\": \"SNAPSHOT\",\n\n        # default pre-release metadata prefix\n        \"meta_pr_prefix\": \"-\",\n\n        # default commit count prefix\n        \"commit_count_prefix\": \".\",\n\n        # Python-based format string variable names are:\n        #     maj, min, patch, rev, rev_prefix, meta_pr_prefix, meta_pr,\n        #     commit_count_prefix, commit_count, build_id, build_id_full\n        #\n        # Note that prefixes will be empty strings if their valued counterpart\n        # doesn't have a meaningful value (i.e., 0 for commit count, no meta\n        # pre-release, ..)\n\n        # format string used to build the current version string when the\n        # commit count is 0\n        \"format\": \"%(maj)s.%(min)s.%(patch)s%(rev_prefix)s%(rev)s%(meta_pr_prefix)s%(meta_pr)s\",\n\n        # format string used to build the current version string when the\n        # commit count is > 0\n        \"format_next\": \"%(maj)s.%(min)s.%(patch)s%(rev_prefix)s%(rev)s%(meta_pr_prefix)s%(meta_pr)s%(commit_count_prefix)s%(commit_count)s+%(build_id)s\"\n    }\n\nThis file gets created automatically in your ``.gitver`` directory when\nyou initialize it with the ``gitver init`` command: should you need to\nregenerate it, for example after updating to a ``gitver`` release that\nadds more configuration options (this will be noted in the ChangeLog or\nby other means), you just need to move/delete the old configuration and\ntrigger regeneration by re-issuing the init command.\n\nBasic usage\n-----------\n\n::\n\n    $ gitver --help\n    usage: gitver [-h] [--ignore-gitignore] [--colors {config,yes,no}] [--quiet]\n                  [--quiet-errors]\n                  \n                  {version,init,check,info,current,list-templates,list-next,update,preview,next,clean,clean-all}\n                  ...\n\n    optional arguments:\n      -h, --help            show this help message and exit\n      --ignore-gitignore    Ignore the .gitignore warning and continue running as\n                            normal (specify this flag before any other command, at\n                            YOUR own risk)\n      --colors {config,yes,no}\n                            Enable or disable colorized terminal output: 'config'\n                            (default) reads the setting from your configuration\n                            file, 'yes' will force-enable it, 'no' will force-\n                            disable it.\n      --quiet               Disable any stdout message.\n      --quiet-errors        Disable any stderr message.\n\n    Valid commands:\n      {version,init,check,info,current,list-templates,list-next,update,preview,next,clean,clean-all}\n        version             Shows gitver version\n        init                Creates gitver's configuration directory and creates\n                            the default configuration file, if it doesn't exist.\n        check               Checks your .gitignore file for gitver's configuration\n                            directory inclusion.\n        info                Prints full version information and tag-based metadata\n                            for this repository. [default]\n        current             Prints the current version information only, without\n                            any formatting applied.\n        list-templates      Enumerates available templates.\n        list-next           Enumerates user-defined next stable versions.\n        update              Performs simple keyword substitution on the specified\n                            template file(s) and place it to the path described by\n                            the first line in the template. This is usually\n                            performed *AFTER* a release has been tagged already.\n        preview             Same as \"update\", but the output is written to the\n                            stdout instead (same rules apply).\n        next                Defines the next stable version for the most recent\n                            and reachable tag.\n        clean               Removes the user-defined next stable version for the\n                            most recent and reachable tag or the specified tag.\n        clean-all           Removes ALL user-defined next stable versions.\n\nIntroduction\n~~~~~~~~~~~~\n\nThe following is an easy-to-follow, step-by-step mini tutorial that will\nwalk you through the features of ``gitver``: we are going to create a\nbrand new repository at ``/tmp/test`` for this.\n\nStep-by-step mini tutorial\n~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nBuilding some repository history\n''''''''''''''''''''''''''''''''\n\nLet's create a new repository in your ``/tmp`` folder:\n\n::\n\n    cd /tmp && mkdir test && cd test && git init\n\nNow populate it with some activity:\n\n::\n\n    echo \"some data\" > some && git add some && git commit -m 'initial commit' && echo \"more data\" > more && echo \"another one\" > another && git add more && git commit -m 'one more' && git add another && git commit -m 'even more'\n\nYour repository should now look like this:\n\n::\n\n    * b01e958  (HEAD, master) (Thu Jan 16 17:08:54 2014) even more (Manuel Bua)\n    * 8f5862b  (Thu Jan 16 17:08:54 2014) one more (Manuel Bua)\n    * fac3511  (Thu Jan 16 17:08:54 2014) initial commit (Manuel Bua)\n\nLet's initialize ``gitver`` at this point:\n\n::\n\n    $ gitver init\n    gitver has been initialized and configured.\n\n``gitver`` just created its own ``.gitver`` configuration directory and\ngenerated the default configuration file ``config`` right there. At this\npoint it's recommended, but not mandatory, to **exclude** gitver's\nconfiguration directory from the repository by adding it to your\n``.gitignore`` file: this is to prevent losing your ``gitver``'s\nconfiguration whenever you checkout old revisions of your project.\n\nAnyway, the tool is quite smart in that and it will *not* proceed if it\ndetects potential problems with the command you issued, in case your\n``.gitignore`` file isn't properly setup, so let's run a check at this\npoint to see that warning message:\n\n::\n\n    $ gitver check\n    Your .gitignore file doesn't define any rule for the .gitver\n    configuration directory: it's recommended to exclude it from\n    the repository, unless you know what you are doing. If you are not\n    sure, add this line to your .gitignore file:\n\n        .gitver\n\nSo let's create your ignore file, add that line, then run ``gitver``:\n\n::\n\n    $ echo \".gitver\" >> .gitignore\n    $ gitver\n    ERROR: Couldn't retrieve the latest tag\n\nRight, we have no tags at this point, so let's create ``v0.0.0`` at the\nfirst commit with this command (replace the commit hash with your own\nwhere needed):\n\n::\n\n    git tag -a v0.0.0 -m 'Initial version' fac3511\n\nThis is how your repository should look like:\n\n::\n\n    * b01e958  (HEAD, master) (Thu Jan 16 17:08:54 2014) even more (Manuel Bua)\n    * 8f5862b  (Thu Jan 16 17:08:54 2014) one more (Manuel Bua)\n    * fac3511  (tag: v0.0.0) (Thu Jan 16 17:08:54 2014) initial commit (Manuel Bua)\n\nNow ``gitver`` output should be somewhat more informative:\n\n::\n\n    Most recent tag: v0.0.0\n    Using NEXT defined as: none, defaulting to -NEXT suffix\n    (Pre-release metadata: none)\n    Current build ID: b01e95831e8c240415510be16e93e10f68fb964a\n    Current version: v0.0.0-NEXT.2+b01e958\n\nTime to decide what the NEXT version numbers will be, so let's set this\nand run ``gitver`` again:\n\n::\n\n    $ gitver next 0.0.1\n    Set NEXT version string to 0.0.1 for the current tag v0.0.0\n\n    $ gitver\n    Most recent tag: v0.0.0\n    Using NEXT defined as: 0.0.1\n    (Pre-release metadata: none)\n    Current build ID: b01e95831e8c240415510be16e93e10f68fb964a\n    Current version: v0.0.1-SNAPSHOT.2+b01e958 => v0.0.1\n\nNotice how the build id stayed the same but the version string changed:\nboth strings describes the same point in development, they are\n*equivalent*, but given the same descriptive intentions, i find the\nlatter to be much more clear.\n\nNow lookup your ``.gitver/config`` file and look at the ``format_next``\ndefinition:\n\n::\n\n    \"format_next\": \"%(maj)s.%(min)s.%(patch)s%(rev_prefix)s%(rev)s%(meta_pr_prefix)s%(meta_pr)s%(commit_count_prefix)s%(commit_count)s+%(build_id)s\"\n\nThis defines the format of the version string being generated at this\npoint of development: since the *commit count* from the most recent\nvalid tag is greater than ``0``, this denotes a *development* build, and\nthe ``format_next`` variation is used: the ``%(meta_pr)s`` placeholder\nwill be replaced by the pre-release metadata if your tag defines one,\nelse the configuration defaults will be used, but this will only happen\nin development builds, there is no point in exposing *pre-release*\nmetadata in a *stable* release.\n\nThe ``%(meta_pr_prefix)s`` counterpart, instead, will be filled with the\nvalue of ``meta_pr_prefix`` *only* if pre-release metadata is used, else\nit will be set to an empty string as well.\n\nThe same reasoning applies to the *commit count*: whenever it's equal to\n``0`` both ``%(commit_count)s`` and ``%(commit_count_prefix)s`` will be\nset to an empty string.\n\nThis permit to adapt and change version string formats by letting you\ndefines concatenations more easily.\n\nTagging a release\n'''''''''''''''''\n\nLet's add that ``.gitignore`` file we didn't add before, then declare\nthe version stable by just tagging it as that:\n\n::\n\n    $ git add .gitignore && git commit -m 'Add .gitignore file'\n    $ git tag -a 'v0.0.1' -m 'Bump version'\n\nYour repository should now look like this:\n\n::\n\n    * 3a3cf5f  (HEAD, tag: v0.0.1, master) (Thu Jan 16 17:29:00 2014) Add .gitignore file (Manuel Bua)\n    * b01e958  (Thu Jan 16 17:08:54 2014) even more (Manuel Bua)\n    * 8f5862b  (Thu Jan 16 17:08:54 2014) one more (Manuel Bua)\n    * fac3511  (tag: v0.0.0) (Thu Jan 16 17:08:54 2014) initial commit (Manuel Bua)\n\nSo let's have ``gitver`` take a look at the repository now:\n\n::\n\n    $ gitver\n    Most recent tag: v0.0.1\n    Current build ID: 3a3cf5ffe0a6a2f6051420ac730554c92bf9bdf2\n    Current version: v0.0.1\n\nAs you can see, ``gitver`` now uses the *other* string format from the\nconfiguration file:\n\n::\n\n    \"format\": \"%(maj)s.%(min)s.%(patch)s%(rev_prefix)s%(rev)s%(meta_pr_prefix)s%(meta_pr)s\"\n\nThis is being used when the commit count from the most recent tag is\nequal to ``0`` since this denotes a *stable* build, rather than a\ndevelopment one.\n\nDepending on your project, format strings can change slightly between\n*stable* and *development* versions: ``gitver`` gives you full control\nover what format to use in each case.\n\nFor completeness, let's use the ``format_next`` format for the stable\nbuild as well and edit that portion of your configuration file to look\nlike this:\n\n::\n\n    \"format\": \"%(maj)s.%(min)s.%(patch)s%(meta_pr_prefix)s%(meta_pr)s%(commit_count_prefix)s%(commit_count)s+%(build_id)s\"\n\nDone that? Now look at ``gitver``'s output now:\n\n::\n\n    $ gitver\n    Most recent tag: v0.0.1\n    Current build ID: 94b2ef2ed92844377f1e8b1160a014bae0273792\n    Current version: v0.0.1+94b2ef2\n\nAs expected, there is no sign of prefixes, nor default metadata or\ncommit count in the stable build.\n\nTemplate-based version information blobs\n----------------------------------------\n\nOne of the main reasons for this tool to exists is to be able to also\nautomatically update your project own's version information *blob* (e.g.\n``VersionInfo.java``, ``version.py``, ...) or some other external file\nwith the project's version information.\n\nTemplate format\n---------------\n\nThe only **required** bit of information *gitver* needs is where the\noutput of the template should be placed, so the first line shall only\ncontain the path to the output file in a Bash-style comment (spaces are\ntrimmed):\n\n::\n\n    # /path/to/project/file.extension\n\nThe rest of the file is obviously up to you, an example is available at\nthe \"Template example\" section.\n\n*Why is the format starting with a Bash-style comment, you say?* The\ninitial version of *gitver* was a Bash script, so it was a natural\nchoice to adopt that: i then realized i didn't like how things were and\nrewrote all it in Python, but the template format stayed the same\nbecause it was *simple*.\n\nTemplate variables\n------------------\n\nGiven these basic assumptions:\n\n-  the latest tag is ``v0.4.9``\n-  the NEXT version numbers have been defined to be ``0.4.10``\n-  the actual commit count is ``2``\n\nHere is the list of variables, with their values, available for use in\ntemplates:\n\n::\n\n    ${CURRENT_VERSION}     = 0.4.10-SNAPSHOT-2/a3a73a58\n    ${BUILD_ID}            = a3a73a58\n    ${FULL_BUILD_ID}       = a3a73a5861e5721055f3a12545201e265ba0c097\n    ${MAJOR}               = 0\n    ${MINOR}               = 4\n    ${PATCH}               = 10\n    ${REV}                 = (empty string, or a revision number if present)\n    ${REV_PREFIX}          = (empty string, or a '.' if a revision number is present)\n    ${COMMIT_COUNT}        = 2 (or 0 if commit count is 0)\n    ${COMMIT_COUNT_STR}    = '2' (or an empty string if commit count is 0)\n    ${COMMIT_COUNT_PREFIX} = either the 'commit_count_prefix' specified in the config file or an empty string, if the commit count is 0\n    ${META_PR}             = either the pre-release metadata from the last reachable tag, the 'default_meta_pr_in_next' (from config file), the 'default_meta_pr_in_next_no_next' (from config file) or an empty string, depending on the state of the repository\n    ${META_PR_PREFIX}      = either the 'meta_pr_prefix' specified in the config file or an empty string, if no pre-release metadata is available for use\n\nThe list could later be expanded and improved, to cover much more\ninformation, such as date, time, let me know your suggestion!\n\nPreviewing and compiling templates\n----------------------------------\n\nYou can preview the result of the template substitution by using the\n``preview``\\ command, followed by one or more template names (multiple\ntemplate names should be quoted):\n\n::\n\n    $ gitver preview my_template\n                or\n    $ gitver preview \"template1 template2 templateN\"\n\nThis will process the template and print the output to the stdout\ninstead of writing it to a file: this can be useful for scripting\npurposes, where you can filter out information messages while only\ncapturing the \"real meat\":\n\n::\n\n    $ gitver preview my_template 2>/dev/null\n\nThe ``update`` command works similarly, it will just write the output to\nthe specified file, rather than stdout:\n\n::\n\n    $ gitver update my_template\n                or\n    $ gitver update \"template1 template2 templateN\"\n\nIt's possible to define any number of templates, just put them in the\n``.gitver/templates`` directory: to have ``gitver`` enumerate all the\navailable templates, use the ``list-templates`` command:\n\n::\n\n    $ gitver list-templates\n    Available templates:\n        version (/home/manuel/dev/gitver/.gitver/templates/version)\n        test (/home/manuel/dev/gitver/.gitver/templates/test)\n\nTemplate example\n----------------\n\nLet's take a look at ``gitver``'s own\n`template <hub.com/manuelbua/gitver/blob/master/.gitver/templates/version>`__:\n\n::\n\n    # gitver/_version.py\n    #!/usr/bin/env python2\n    # coding=utf-8\n\n    # DO NOT TOUCH, AUTOMATICALLY UPDATED!\n    gitver_version = '${CURRENT_VERSION}'\n    gitver_buildid = '${FULL_BUILD_ID}'\n    gitver_pypi = '${MAJOR}.${MINOR}.${PATCH}${META_PR_PREFIX}${META_PR}${COMMIT_COUNT_PREFIX}${COMMIT_COUNT_STR}'\n\nNow let's compile it:\n\n::\n\n    $ gitver update version\n    Processing template \"version\" for /home/manuel/dev/gitver/gitver/_version.py...\n    Done, 207 bytes written.\n\nThis will produce the following file at\n``/home/manuel/dev/gitver/gitver/_version.py``, **overwriting** the\nprevious file, if any:\n\n::\n\n    #!/usr/bin/env python2\n    # coding=utf-8\n\n    # DO NOT TOUCH, AUTOMATICALLY UPDATED!\n    gitver_version = '0.3.0-RC1.47+1d170e7'\n    gitver_buildid = '1d170e7f42817d0f277c52ad686b24ac69b353d4'\n    gitver_pypi = '0.3.0-RC1.47'\n\nTemplates + git hooks\n---------------------\n\nAt this point is very simple to automatize even more, instead of\nmanually updating version information after each commit, let's create a\ngit hook to take care of this:\n\n::\n\n    $ cat .git/hooks/post-commit \n    #!/bin/bash\n    # gitver should be in your path to work!\n    gitver update version\n\nThere you have it!\n\nBugs\n----\n\n.. figure:: http://media.giphy.com/media/10EdqIfzllpg6A/giphy.gif\n   :alt: bugs\n\n   bugs\nNOPE!! MY CODE HAS NO BUGS!11\n\nJust joking, probably quite a few, please report them\n`here <https://github.com/manuelbua/gitver/issues>`__, thanks!\n\n.. |PyPi version| image:: https://pypip.in/v/gitver/badge.png\n   :target: https://crate.io/packages/gitver/\n.. |PyPi downloads| image:: https://pypip.in/d/gitver/badge.png\n   :target: https://crate.io/packages/gitver/\n.. |Project Stats| image:: https://ohloh.net/p/gitver/widgets/project_thin_badge.gif\n   :target: https://ohloh.net/projects/gitver\n.. |Flattr this git repo| image:: http://api.flattr.com/button/flattr-badge-large.png\n   :target: https://flattr.com/submit/auto?user_id=manuelbua&url=https://github.com/manuelbua/gitver&title=gitver&language=&tags=github&category=software",
        "description_content_type": null,
        "docs_url": null,
        "download_url": "UNKNOWN",
        "downloads": {
            "last_day": -1,
            "last_month": -1,
            "last_week": -1
        },
        "home_page": "https://github.com/manuelbua/gitver",
        "keywords": null,
        "license": "Apache License, Version 2.0",
        "maintainer": null,
        "maintainer_email": null,
        "name": "gitver",
        "package_url": "https://pypi.org/project/gitver/",
        "platform": "UNKNOWN",
        "project_url": "https://pypi.org/project/gitver/",
        "project_urls": {
            "Download": "UNKNOWN",
            "Homepage": "https://github.com/manuelbua/gitver"
        },
        "release_url": "https://pypi.org/project/gitver/0.3.1/",
        "requires_dist": null,
        "requires_python": null,
        "summary": "Simple version string management for git",
        "version": "0.3.1"
    },
    "last_serial": 974002,
    "releases": {
        "0.2.1": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "35bec5438e98d22008280e1a555638c7",
                    "sha256": "8ed48645eb3f16781deaa053b703c16dcae4e8e9315b82aa61b682406ed193fb"
                },
                "downloads": -1,
                "filename": "gitver-0.2.1.tar.gz",
                "has_sig": false,
                "md5_digest": "35bec5438e98d22008280e1a555638c7",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 20250,
                "upload_time": "2014-01-06T19:31:19",
                "url": "https://files.pythonhosted.org/packages/6f/eb/adf4f8f37e2de367190faf55e4116c3abffb2a3e9c504fd3ff0d53646cfa/gitver-0.2.1.tar.gz"
            }
        ],
        "0.2.2": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "ed0d01a3acb31007dc223c186258a0b7",
                    "sha256": "fbc116c3184928b8f744381423e38fbbee37927933d9df9ba9c5f01bc7ee86d4"
                },
                "downloads": -1,
                "filename": "gitver-0.2.2.tar.gz",
                "has_sig": false,
                "md5_digest": "ed0d01a3acb31007dc223c186258a0b7",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 21082,
                "upload_time": "2014-01-07T01:09:43",
                "url": "https://files.pythonhosted.org/packages/72/44/ef16df69461f4c178ca7323ece9a61411aed2b4b266b8ce53abecd2a631d/gitver-0.2.2.tar.gz"
            }
        ],
        "0.2.4": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "0f1495e24def728b95bdebd187f18b8e",
                    "sha256": "5f89f9da614d4da29cc701d0877c4c54bb9d24e3f824475b429697d9aff3335e"
                },
                "downloads": -1,
                "filename": "gitver-0.2.4.tar.gz",
                "has_sig": false,
                "md5_digest": "0f1495e24def728b95bdebd187f18b8e",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 21320,
                "upload_time": "2014-01-07T21:45:11",
                "url": "https://files.pythonhosted.org/packages/c2/82/4ee464ced6b8ff04f71f1bf8ad2f30ae91fa143dd609c57548a2f52a4117/gitver-0.2.4.tar.gz"
            }
        ],
        "0.3.0": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "9020e9e214021b66e2821ac16fccfb63",
                    "sha256": "565b64108a30309561e7189b8f5eb9deca2f197c33e3f1d3fcefeec63ad7d978"
                },
                "downloads": -1,
                "filename": "gitver-0.3.0.tar.gz",
                "has_sig": false,
                "md5_digest": "9020e9e214021b66e2821ac16fccfb63",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 28954,
                "upload_time": "2014-01-18T19:24:41",
                "url": "https://files.pythonhosted.org/packages/56/cd/698bf588dde8ddf45a140e6331185f63ce76b586952b06ff35d55f381df5/gitver-0.3.0.tar.gz"
            }
        ],
        "0.3.1": [
            {
                "comment_text": "",
                "digests": {
                    "md5": "4dd21a2dfe3d429f0bb2b9a4be428071",
                    "sha256": "d97b4b582560147b59ec596b8fb6d572ef82769952e5f905af4510f6c7c0ba4a"
                },
                "downloads": -1,
                "filename": "gitver-0.3.1.tar.gz",
                "has_sig": false,
                "md5_digest": "4dd21a2dfe3d429f0bb2b9a4be428071",
                "packagetype": "sdist",
                "python_version": "source",
                "requires_python": null,
                "size": 28919,
                "upload_time": "2014-01-19T15:22:16",
                "url": "https://files.pythonhosted.org/packages/f2/a6/2f8677fe762d48fbd25e0cb90b9ea9f733daf3000c39aa8863c04d5aac84/gitver-0.3.1.tar.gz"
            }
        ]
    },
    "urls": [
        {
            "comment_text": "",
            "digests": {
                "md5": "4dd21a2dfe3d429f0bb2b9a4be428071",
                "sha256": "d97b4b582560147b59ec596b8fb6d572ef82769952e5f905af4510f6c7c0ba4a"
            },
            "downloads": -1,
            "filename": "gitver-0.3.1.tar.gz",
            "has_sig": false,
            "md5_digest": "4dd21a2dfe3d429f0bb2b9a4be428071",
            "packagetype": "sdist",
            "python_version": "source",
            "requires_python": null,
            "size": 28919,
            "upload_time": "2014-01-19T15:22:16",
            "url": "https://files.pythonhosted.org/packages/f2/a6/2f8677fe762d48fbd25e0cb90b9ea9f733daf3000c39aa8863c04d5aac84/gitver-0.3.1.tar.gz"
        }
    ]
}