Metadata-Version: 1.1
Name: jmeslog
Version: 0.0.1
Summary: Tool for managing changelogs.
Home-page: https://github.com/jamesls/jmeslog
Author: James Saryerwinnie
Author-email: js@jamesls.com
License: Apache License 2.0
Description: JMESLog - Changelog Management
        ==============================
        
        JMESLog is a script for managing changelogs.  It helps you associate changelog
        entries for new features and bug fixes and also helps you generate a CHANGELOG
        file or any other type of release notes page.  It enforces semver by
        automatically determining the next version number based on the pending
        changes for your next release.
        
        
        Quickstart
        ==========
        
        Initialize a repo to use JMESLog::
        
            $ jmeslog init
        
        Before you send a PR, create a changelog entry for your change::
        
            $ jmeslog new-change
        
            A change file was created at .changes/next-release/foo-bar.json
        
        Commit that file::
        
            $ git add .changes/next-release/foo-bar.json
            $ git commit -m "Add changelog entry"
        
        That's it.
        When it comes time to release, you run these commands::
        
            $ jmeslog new-release
            $ jmeslog render > CHANGELOG.rst
        
        The ``new-release`` command consolidates all the files in
        ``.changes/next-release`` into a single JSON file representing
        the new release.  The ``render`` command regenerates your CHANGELOG
        file.
        
        The rest of this doc explains this workflow in more detail.
        
        
        Concepts
        ========
        
        All changes for a repo are stored as structured data in a
        ``.changes/`` directory.
        
        The changes for the next release are stored in ``.changes/next-release/``.
        All of the changes from previous releases are stored in
        ``.changes/X.Y.Z.json`` where ``X.Y.Z`` represent the version associated
        a given release.  These files are generated by running the
        ``jmeslog new-change`` command.
        
        When you're ready to release a new version, all of the change files from
        ``.changes/next-release/`` are gathered and a new ``.changes/X.Y.Z.json``
        file is created that contain those changes.  The content from
        ``.changes/next-release/`` is then removed.  This is done with the
        ``jmeslog new-release`` command.
        
        You can then generate a CHANGELOG (or any other file) using the data
        from ``.changes/``.  To do this you run the ``jmeslog generate`` command.
        
        
        Usage
        =====
        
        The typical workflow when using ``jmeslog``:
        
        * Use the ``jmeslog new-change`` command to generate a new changelog
          file when you're working on a new feature.  This file is included
          as part of the PR you send.
        * When you're ready to release, you can run the ``jmespath generate``
          command to generate the CHANGELOG file based on all your change files.
          You also run the ``jmeslog new-release`` command to consolidate files
          from the next ``.changes/next-release/`` directory into a new single
          ``.changes/X.Y.Z.json`` file.
        
        Backwards Compatibility
        =======================
        
        The API for JMESLog, including the CLI commands and parameters, the
        files generated and the functionality provided by JMESLog may
        change in a backwards incompatible manner until its 1.0.0 GA release.
        
        
        FAQ
        ===
        
        **What problem is this trying to solve?**
        
        JMESLog helps you automate releases.  It's the result of iterating on an
        automated release process that started from a completely manual process to
        eventually releasing every single day.  When you think about what's involved
        in releasing a new version of your library/tool, you have to:
        
        * Figure out the next version number you want for your release.  If you're
          following semver, this will depend on what types of changes will be in
          the next release.  New features should require a minor version bump,
          and bug fixes should result in a new patch version.
        * Update your CHANGELOG with all the new changes that will be part of
          this next release under a new section corresponding to the next version
          number.
        
        This tool helps with manage both of these problems so you can completely
        automate your release process.  It also solves several other problems
        that come up:
        
        * You can have changelog entries tracked with each pull request, and
          you don't have to worry about merge conflicts to your CHANGELOG file.
        * You can generate more than just a CHANGELOG file if needed.  For example,
          you can create a "History" page in your docs that's rendered differently
          than your CHANGELOG.
        * You can programatically query for a projects changes.
        
Keywords: changelog jmeslog changes
Platform: UNKNOWN
Classifier: Development Status :: 3 - Alpha
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: Apache Software License
Classifier: Natural Language :: English
Classifier: Programming Language :: Python :: 3.7
