DWS WP Framework
  • Welcome
  • Primary goals
    • Modular design
    • No 3rd-party dependencies
  • Key concepts and dev tools
    • PHP and WP requirements
    • Object-Oriented Programming
    • Semantic Versioning
    • Version Control (git / GitHub)
    • Dependency Management (Composer)
    • Automated Testing (Codeception + Github Actions)
    • Dependency Injection (PHP-DI)
    • Coding Standards (PHPCS and PHPMD)
    • Dependencies Scoping (PHP-Scoper)
    • TypeScript and Sass
    • Task Runners (Grunt)
  • Setting up your dev environment
    • Windows
  • Your first plugin
    • Multiple plugins using the framework on the same site
  • Frequently Asked Questions
  • Bootstrapper Module
    • Motivation
    • How it works
    • How to use
    • White Labeling
  • Helpers Module
    • Motivation
    • How to use
  • Foundations Module
    • Motivation and How to use
    • Actions
      • Local action traits
      • Extension action traits
      • Integration action traits
    • States
    • Utilities
      • Stores
      • Handlers and Services
        • Logging Service
  • Plugin
    • Main Plugin Instance
    • Plugin Components
  • Hierarchies
  • Helpers
  • Utilities Module
    • Motivation and How to use
    • Hooks Service
      • Scoped Handler
    • Shortcodes Service
    • Templating Service
    • Assets Service
      • Scripts Handler
      • Styles Handler
    • CRON Events Service
      • Action Scheduler Handler
    • Admin Notices Service
    • Dependencies Service
    • Validation Service
  • Core Module
    • Motivation and How to use
    • Plugin Tree
      • Plugin Root
      • Plugin Functionality
    • Plugin Components
      • Internationalization
      • Installation / Upgrade / Uninstallation
  • Settings Module
    • Motivation and How to use
    • Settings Service
      • WordPress Handler
      • MetaBox Handler
      • ACF Handler
    • Validated Settings
  • WooCommerce Module
    • Motivation and How to use
    • Extended WC Logger
    • WC Settings Handler
Powered by GitBook
On this page

Was this helpful?

  1. Key concepts and dev tools

Semantic Versioning

PreviousObject-Oriented ProgrammingNextVersion Control (git / GitHub)

Last updated 4 years ago

Was this helpful?

The concept of , or SemVer for short, is simple — developers should be able to tell at a glance whether an update is likely to cause problems or not. We promise to make releases in a manner that is compatible with SemVer. In a nutshell:

  • All releases of the form A.*.* will be compatible with each other. Version B.*.* is guaranteed to break everything.

  • All releases of the form A.B.* are simple bug-fixes. It should be a no-brainer to update from A.B.C to A.B.D, no matter what C and D are, and we guarantee as much as humanely possible that everything will keep working.

  • All updates from A.B.* to A.C.* contain new features, but as much as humanely possible, won’t break any existing functionality.

As a rule of thumb, updates are by definition risky and you should always test them in a staging environment first. But using SemVer, we try our best to offer you bite-sized updates that explain the differences between them at a glance.

semantic versioning