How Releases Work

Our philosophy has always been that it's a bad idea to hold onto bugfixes for political/appearance reasons. Generally speaking, master is stable, and if you keep your version at parity with master, you'll be in good shape. However we also know some folks only want to upgrade from a tagged release, so it makes more sense to us to get fixes in your hands sooner rather than later -- so we release often.

For transparency, we document what it takes to make a release happen. This is the checklist we ourselves use before tagging a release, once all testing has been completed and a feature or bug fix has been deemed important enough to warrant a release.

Create a draft release on Github based on the new version tag
Review CrowdIn to see if there are new translations that need proofreading/approval
Generate and download a translation zip file from CrowdIn and validate/merge changes
If a new language was added and has more than 20% completed translations, add it to the Form::macro('locales') method in resources/macros.php to make it available for selection in the locales list. We use the accepted abbreviations for locales, which can be gleaned via the language URL in CrowdIn. We also update the list of available localizations in the documentation
Review changes between the last release and current on develop or master (based on what branch we're releasing). We do this by going to our repo, clicking on "Releases", clicking on "x commits to since this release", and visually reviewing changes.
Run php artisan version:update to generate an updated version/hash in config/version.php and commit that updated file
Generate the release notes based on the commits since the last release. This includes a summary of critical changes, and a line-by-line walkthrough of commits. If new features have been added, this may also include generating screenshots/gifs to highlight the changes.
Review changes to the documentation site (this site) and include links to new/updated documentation
Update the links in the release notes template to point to the updated diff view ("For a full list of changes, see the changelog.")
Include any special instructions that might be needed for that particular release
Publish the release
Announce the release on Twitter/Facebook/project blog

We make a concerted effort to use semver consistently, however there may be times when it's not practical. For example, the minimum PHP requirement change that came with v4.7 (because we had to upgrade the Laravel framework version to handle a security vulnerability) would typically call for a major version bump, however because Snipe-IT v5 was already an anticipated release that's been planned, developed and discussed for several months, we felt it would be more confusing to bump it to a major version (and have people wondering where all of the new v5 features are) than to call it v4.7. It was a difficult decision, but as with all of the choices we make, we spent time evaluating the options and picked the one we felt would be the least disruptive to our users overall.

Open source projects are challenging in ways closed-source projects are not (and also in the ways they are, so that's fun.)

We try to provide an upgrade path from any point in time (where system requirements allow) - and frequently have folks who are upgrading from a literal alpha pre-release of v1 from 2014. While we obviously wish folks upgraded a little more often, we also know not everyone has that choice. Sometimes folks starting a new job end up inheriting a very old version of Snipe-IT that hasn't been upgraded in years, and we consider it our responsibility to make it possible (if not always easy, because of system requirements) for you to upgrade to latest.