Metadata-Version: 2.1
Name: CuteJoe
Version: 0.1.1
Summary: Commands to automate some release tasks
Home-page: https://github.com/MatheusBrochi/CuteJoe
Author: MatheusBrochi
Author-email: matheusgbrochi@gmail.com
License: MIT License
Project-URL: Changelog, https://github.com/MatheusBrochi/CuteJoe/tree/master/changelogs
Project-URL: Issue Tracker, https://github.com/MatheusBrochi/CuteJoe/issues
Description: # CuteJoe
        > Commands to automate some release tasks.
        
        ![Comb](./comb.svg)
        
        ## Installation
        
        ### Or on the local machine
        ```sh
        pip install cutejoe
        ```
        
        ## Usage
        
        Some commands are available on CLI. To see all available commands, type:
        
        ```sh
        cutejoe --help
        ```
        
        ## Commands
        
        ### Configuration File
        > Script to create default configuration file.
        
        ```sh
        cutejoe config-file --help
        ```
        
        `start` and `end` are the range commits to get the log messages.
        `folder` is where the changelogs will be saved.
        `kinds` are composed of:
            - labels (prefix of the commit messages),
            - title (title of this kind section),
            - version (`major`, `minor` or `patch`).
        `default_title` is the title used if the commit message has no valid kind.
        
        ### Changelog
        > Script to generate changelog based on the commit messages.
        
        ```sh
        cutejoe changelog --help
        ```
        
        #### Changes on changelog generation
        
        For every PR, the reviewer will be required to follow this pattern when "squash and merge" the PR:
        
        `<kind>:<message>`
        
        The kind and message must be written by the PR owner on the PR message. The reviewer must only copy the kind and message to the merge commit body.
        
        
        **\* Valid kinds:**
        - `break`: fix or feature that would cause existing functionality to not work as expected;
        - `add`: non-breaking change that adds functionality;
        - `change`: non-breaking change that changes existing functionality;
        - `deprecate`: non-breaking change that deprecates existing functionality;
        - `remove`: non-breaking change that removes existing functionality;
        - `security`: non-breaking change that fixes existing vulnerability;
        - `fix`: non-breaking change that fixes existing issue.
        
        (kinds are defined on the configuration file)
        
        \*\*If someone forget to prefix with the kind, the message will be on the `Uncategorized` subsection.
        
        
        _Example:_
        
        `add:script to generate changelog based on commit messages`  *<- THIS MESSAGE MUST BE COPIED TO THE MERGE COMMIT MESSAGE*
        
        
        #### Changes on release and tag process
        
        When a release is to be made, we checkout to the `develop` specific commit and run this command:
        
        ```sh
        cutejoe changelog
        ```
        
        The changelog is created to the `/changelog` folder and the release branch name is printed on the screen, like `release/v1.0.1`
        
        #### Template for the `.github/PULL_REQUEST_TEMPLATE.md` of your project
        
        In order to standardize the PR commit messages, it's desirable to create/change the `.github/PULL_REQUEST_TEMPLATE.md`:
        
        ```markdown
        ## Squash and Merge Message
        
        Please write the merge message:
        
        `<type*>:<message>`
        
        **\* Valid types:**
        - `break`: fix or feature that would cause existing functionality to not work as expected;
        - `add`: non-breaking change that adds functionality;
        - `change`: non-breaking change that changes existing functionality;
        - `deprecate`: non-breaking change that deprecates existing functionality;
        - `remove`: non-breaking change that removes existing functionality;
        - `security`: non-breaking change that fixes existing vulnerability;
        - `fix`: non-breaking change that fixes existing issue.
        ```
        (kinds are defined on the config file, change the valid types section according to your config file)
        
        ### Template for the `README.md` of your project
        
        It's advisable to inform on the `README.md` the PR commit pattern adopted by your project:
        
        ```markdown
        This project follows the [CuteJoe PR commit pattern and changelog](https://github.com/MatheusBrochi/CuteJoe).
        ```
        
        ## TODOs
        
        - Commands to automate the entire release process (create branch, change version, etc);
        
Platform: UNKNOWN
Classifier: Development Status :: 3 - Alpha
Classifier: Environment :: Console
Classifier: Intended Audience :: Developers
Classifier: Intended Audience :: System Administrators
Classifier: Programming Language :: Python :: 2
Classifier: Programming Language :: Python :: 3
Classifier: License :: OSI Approved :: MIT License
Classifier: Topic :: Software Development :: Documentation
Description-Content-Type: text/markdown
Provides-Extra: test
