https://github.com/chippyash/semantic-version-updater
PHP utility program to enable version updating in the build chain
https://github.com/chippyash/semantic-version-updater
Last synced: about 1 month ago
JSON representation
PHP utility program to enable version updating in the build chain
- Host: GitHub
- URL: https://github.com/chippyash/semantic-version-updater
- Owner: chippyash
- License: gpl-3.0
- Created: 2017-07-10T17:26:17.000Z (almost 9 years ago)
- Default Branch: master
- Last Pushed: 2021-05-22T10:45:51.000Z (about 5 years ago)
- Last Synced: 2025-12-01T14:53:24.058Z (7 months ago)
- Language: PHP
- Size: 2.19 MB
- Stars: 0
- Watchers: 1
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE.md
Awesome Lists containing this project
README
# Semantic Version Updater
Build chain utility to update the semantic version for a PHP package
## PHP Version support
With the inexorable withdrawal of upstream library support for PHP
git commit -am"add vupdate"
git tag 0.0.0
git push origin master --tags
### Manually updating the version and git tag
During initial development, you'll want to have your package tagged at various points. You can keep your git tag version
and the version contained in the VERSION file in sync with
bin/vupdate && cat VERSION | xargs git tag
Don't forget to push your tags to remote repo.
Once you have finished initial development and you think you are good to go,
you can tag you package at its first 'real' release version. You can
either run `bin/vupdate -pbcbreak` to update the major (M.n.n) part of
the version number, or `bin/vupdate -o 1.0.0` to force the version. A one liner would be
bin/vupdate -pbcbreak && cat VERSION | xargs git tag && git commit -am"First release" && git push origin master --tags
Use `bin/vupdate -h` to see the help screen.
Use `bin/vupdate --version` for command version number.
### Employing into your build chain
The real purpose of the utility is to get it used in the build chain,
updating the tag, pushing to git and then updating the Satis/Composer
(or other repo) to tell it that a new version is available.
Download this repo as a zip and extract it. Move/copy the bin/vupdate
file to somewhere on your PATH, e.g. /usr/local/bin/vupdate. You can also do
this if you just want the executable phar on your local machine to be
globally available.
Here is a jenkins job that we use in our build chain to update the version dependent
on the branch name prefix:
VERSIONER=/usr/local/bin/vupdate
GIT=git
cd "${workingDir}";
${GIT} checkout ${gitBranch};
lastCommit=$(git log --branches | grep 'Merge pull request.* to master' | head -1)
if [[ $lastCommit == *"feature/"* ]] || [[ $lastCommit == *"release/"* ]]
then
${VERSIONER} -p feature;
verType="Feature";
else
${VERSIONER};
verType="Patch";
fi;
${GIT} commit -am"CD $verType Version update: $lastCommit";
cat VERSION | xargs ${GIT} tag;
${GIT} push origin ${gitBranch} --tags;
The $workingDir and $gitBranch parameters are sent to the job from the main build
job. $gitBranch defaults to 'master';
## Development
Clone the repo as normal.
Create a feature branch
run `composer update` to pull in the external libraries.
Commit your changes as normal and push to repo and make a pull request.
### The make file
Running `make` will rebuild the `bin/vupdate` phar file and push the changes to the repo.
As such, it is only of any use to you if you have write access on the code repo.
You can run `make build` to just build the `bin/vupdate`
### Notes
If you get `creating archive "/var/lib/jenkins/jobs/ci-version-updater-builder/workspace/bin/vupdate.phar"
disabled by the php.ini setting phar.readonly `
or something similar when using the make build tools, edit your php cli
ini file and set `phar.readonly = Off`.
## Acknowledgments
I first wrote the vupdate.php script some years ago. At that time it relied on the
'herrera-io/version' package from [Kevin Herrara](https://packagist.org/users/kherge/). He's since abandoned that package, so
I've included his original code in the source of this package. It still works just fine.
You can find it in the 'src' directory, along with his original tests in the 'test'
directory. The Test Contract can be found at `docs/Test-Contract.md`. He has
a permissive license on his code, so feel free to use this package
to get access to the original code if you need it in some other application.
The build routine managed by the Makefile relies on [Box](https://box-project.github.io/box2/).
There is a box phar distribution in the bin directory which will be used
by the makefile.