PHPackages pdga/exception - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. pdga/exception ActiveLibrary pdga/exception ============== Custom exception classes used by the PDGA. 1.4.0(2y ago)06.8k↓50%1[1 PRs](https://github.com/PDGA/php-exceptions/pulls)2MITPHPPHP >=7.4.0 Since Aug 29Pushed 1y ago3 watchersCompare [ Source](https://github.com/PDGA/php-exceptions)[ Packagist](https://packagist.org/packages/pdga/exception)[ Docs](https://github.com/PDGA/php-exceptions)[ RSS](/packages/pdga-exception/feed)WikiDiscussions develop Synced 1mo ago READMEChangelogDependenciesVersions (7)Used By (2) php-exceptions ============== [](#php-exceptions) Branching for features and bug fixes ------------------------------------ [](#branching-for-features-and-bug-fixes) When creating a new feature or bug fix, you will typically start by ensuring you are on the `develop` branch and use the following command to create your new branch: `git checkout -b ` If there is a Jira ticket for your task then using that ticket number and title is a good candidate for your branch name but as long as it is clear what your branch is for then you can use anything you wish. Note that you do not always have to branch off of `develop`, for instance if you are making a change to something that isn't merged into `develop` yet you will want to branch off of that other existing branch. It is important to remember which branch you branched off of so that you merge back into that branch. Once your changes are committed and pushed up, you are ready to make a Pull Request on GitHub. In your web browser, navigate to and click New Pull Request. Ensure that the branch selected in the `base` dropdown is the branch you branched off of, and the option selected in the `compare`dropdown is your branch. Click Create Pull Request and add a description of your change in the `Add a description` section. Make sure you select at least two people as reviewers and then click `Create Pull Request` below the description box to open the Pull Request. Merging a Pull Request ---------------------- [](#merging-a-pull-request) Once at least two people have approved your Pull Request it may be merged. There are two ways to do this: You can either use the GUI on GitHub to automatically merge your branch into the branch you selected as `base`and then subsequently delete your branch, or you can use the `git` command line to do the same. ### Using GitHub [](#using-github) The `Merge pull request` button on GitHub is at the bottom of the main Pull Request page and once clicked it will turn into a `Delete Branch` button. After the branch is deleted you should change which branch you are working in locally to the one you select as `base` and run the following commands: ``` git fetch -p git pull ``` ### Using git command line [](#using-git-command-line) To use the `git` command, first change your current working branch to your `base` branch. Then use the following command to merge your branch. `git merge ` Once the merge is complete and any conflicts have been resolved and committed you must push up the `base` branch. NOTE: Changes can not be committed and pushed directly to `develop` from the command line, so if your `base` branch was `develop` please see the above instructions for using the GitHub GUI for merging. At this point you can delete your branch from the origin: `git push -d origin ` ### After merging and deleting remotely [](#after-merging-and-deleting-remotely) After deleting the branch from the origin, either manually or via GitHub, make sure to delete it locally: `git branch -d ` Releasing a new version ----------------------- [](#releasing-a-new-version) To release a new version of the repository, all changes need to be merged into `develop` via a Pull Request. Changes can not be committed and pushed directly to `develop` from the command line, so a Pull Request is required. When you intend to release a new version you will also want to update the `CHANGELOG.md` file with a list of changes made under the new version number you intend to release (See below for information about version numbers). Once all changes have been merged into `develop` it needs to be merged into `main`, again via a Pull Request. Once everything is merged into `main` a new tag can be created for the repository and pushed. ### Creating a new tag [](#creating-a-new-tag) A new tag for the repository should be created using the following naming scheme: <major-version.minor-version.bug-fix> The major version should be incremented whenever breaking changes are added to the repository code. The minor version should be incremented when non breaking, non bug fix changes are made to the repository code. The bug fix version should be incremented when only bug fixes are added to the repository code. Note that incrementing a version number sets all version number to the right of that number to 0. For example, if a breaking change is made to version `1.4.29` you would go from `1.4.29` to `2.0.0`, NOT `2.4.29`. To create a new tag, use the following command from the command line: `git tag -a -m ""` followed by `git push -u origin ` Using the package in other applications --------------------------------------- [](#using-the-package-in-other-applications) This package can be used in other PHP applications via Composer. It is available for inclusion via Composer from Packagist. ### Pushing a new version of the package to Packagist [](#pushing-a-new-version-of-the-package-to-packagist) This package is already set up on Packagist, which watches the repository for new tag and automatically creates a new release version for use via Composer (The Packagist page can be found at ). Therefore, the simple act of pushing a new tag to the repository will trigger a new version to be available in Composer. Sometimes it can take a bit of time for the new version to become available. You can verify that the new version is available on the Packagist page. ### Adding the package to another application [](#adding-the-package-to-another-application) To add the package to an application's Composer dependencies, use the following Composer command: `composer require pdga/exception` You will also use the above command to update the package if it is already being used in your application but the major version number has been changed. If you want to update an existing dependency on this package and only the minor or bug fix version has been changed you can use the following command in that application: `composer update pdga/exception` The above commands are very simple, however there are many options as far as dictating which versions are installed that can be used. For more information see [the official Composer documentation](https://getcomposer.org/doc/articles/versions.md#writing-version-constraints). Install Composer Dependencies ----------------------------- [](#install-composer-dependencies) ``` ./bin/composer install ``` Code Formatting Standards ------------------------- [](#code-formatting-standards) #### Run PHP\_CodeSniffer to see the existing styling issues. [](#run-php_codesniffer-to-see-the-existing-styling-issues) - [CLI Reference](https://github.com/squizlabs/PHP_CodeSniffer/wiki/Usage#getting-help-from-the-command-line) ``` ./bin/codesniffer ``` #### Run the formatter to automatically fix the styling issues that can be fixed. [](#run-the-formatter-to-automatically-fix-the-styling-issues-that-can-be-fixed) - [CLI Reference](https://github.com/squizlabs/PHP_CodeSniffer/wiki/Fixing-Errors-Automatically#using-the-php-code-beautifier-and-fixer) ``` ./bin/codeformatter ``` ### Health Score 32 — LowBetter than 72% of packages Maintenance27 Infrequent updates — may be unmaintained Popularity24 Limited adoption so far Community18 Small or concentrated contributor base Maturity51 Maturing project, gaining track record Bus Factor2 2 contributors hold 50%+ of commits How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Every ~145 days Total 5 Last Release 776d ago ### Community Maintainers ![](https://www.gravatar.com/avatar/9806d5f419b90980d81095a16b1be2b698f203e92e74ea0e27e5b7ffd05d1ed1?d=identicon)[pdga](/maintainers/pdga) --- Top Contributors [![timallen527](https://avatars.githubusercontent.com/u/3316521?v=4)](https://github.com/timallen527 "timallen527 (11 commits)")[![drew-acheson](https://avatars.githubusercontent.com/u/96074290?v=4)](https://github.com/drew-acheson "drew-acheson (6 commits)")[![benbotto](https://avatars.githubusercontent.com/u/14243981?v=4)](https://github.com/benbotto "benbotto (5 commits)")[![pcrist](https://avatars.githubusercontent.com/u/4089091?v=4)](https://github.com/pcrist "pcrist (4 commits)") ### Embed Badge ![Health badge](/badges/pdga-exception/health.svg) ``` [![Health](https://phpackages.com/badges/pdga-exception/health.svg)](https://phpackages.com/packages/pdga-exception) ``` PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)