I normally don't use anything like that. My applications have their own version number. For example we now did an upgrade of an application from 5.6 to 5.7 but the version went from 2.3 to 2.4. There is no breaking change so a new version is needed in this case.
Also the Laravel version number is available in the composer.json and composer.lock file. So with a single composer command you can see what version is installed or by running php artisan --version of course.
May I ask why you want to keep track of the Laravel version in your application? :D
Sorry @bobbybouwmann, no, not the Laravel version but a version of my application. I want a version number that I can link to release notes and mark major upgrades etc.
I'm trying to establish what my workflow would be to deploy V4.0.0 then V4.0.1,2,3 etc and then when a new feature drops, V4.1.0 etc
I would personally use git to get the version number. You can execute an artisan command that gets the current branch name or tag name and you can display that! As long as you deploy using git and stuff this should be possible ;)
@Snapey Not in my own applications, no. They have test suites, and users don’t care about version numbers (most of them don’t care about error messages as they’ll tell you they got an error, but not what it said).
We create version numbers for our applications by tagging each release as well. I think it's only usefull if you have more then one installation of the same codebase running on multiple environments.
Not to toot my own horn, but I actually just wrote a package to handle this as well (https://github.com/nlmenke/deploy-version). Each "deployment" (like a migration) you run will increment the version number.
I still have a few minor things I want to do with it and tests to write, but others using it would be helpful in it's development.
@click Thanks but I know what semantic versioning is. The question is how to get it into your application so that it can be displayed and multiple sites ostensibly running the same code base can display their version number
@Snapey ah sorry, I misunderstood your question. No I do not show the version number at this moment but I did the following once:
# get the last commit hash
git log --pretty="%h" -n1 HEAD
# get the last tag name
git describe --tags --abbrev=0
You could play around with the git commands to retrieve the current git hash, last commit date, current branch, or current git tag (actual version number if you tag them correctly). You could wrap this in an artisan command or another script that you execute on each deployment. Maybe depending on the environment you are deploying on you could store the current version into a .version file. And just read the version file in your application.
4 years late, but able to share the adopted approach? I have an auto semver tagger, I'm thinking of making it write to a file that exists in production only, then the project can read off this file (if it exists).
