This article addresses core ConfigBox developers and designers. It gives orientation on releases, breaking changes and VCS commits.
Major releases come out every 12-18 months and are allowed to have breaking changes to customizations. Numbering is 3.x, 4.x etc.
Within minor releases, there cannot be breaking changes to things that can be customised, specifically (but not limited to)
Custom styling and calls to JS AMD module methods
Template overrides
Custom views
Wording overrides in custom language files
Public methods of core models, Kenedo framework classes and CB's static helper classes
Note: In case a new feature's value or considerably better code organisation warrants a breaking change within a major release, then discuss advantages and alternatives with your head developer. Breaking changes must be well documented on the public Breaking Changes Page. For the breaking changes page, you must write a concise description and straight-forward instructions on adapting their customizations.
On feature development that take more than a week, you create a branch and merge into master on completion.
Mention the feature you worked on in the commit. As of now there are no task or ticket numbers, use concise and meaningful comments useful for colleagues.
On changes to CSS and JS, commit the minified versions as well (Use YUI compressor and Closure Compiler via PHPStorm's File Watchers).
Assets are served with Far Future Headers even on development and Kenedo adds a cache busting query string on resource URLs. See this article.
Use your browser's cache disabling feature.
In the CB settings at 'Analysis and Debugging' you can turn off use of minified CSS and/or JS and also turn off the use of the cache-busting query string
In customization projects, you find a file getReleaseNumber.php in the customization folder in 'system_overrides'. Bump up the version number on any commit that has changes to assets.