One of the greatest advantages of SwatFlow is the possibility to maintain all the previously released version and provide fixes to the oldest ones as easy as to the newest ones.
The main idea is that each release allows the creation of a hotfix branch from its tag, providing an isolated snapshot of the state of the project at the time of the actual release.
This allows for easy investigation and implementation of a fix, without being hindered by the SwatFlow in any way.
But despite its full flexibility, SwatFlow doesn't allow the update of older release relative to a 'major.minor' release group.
For instance, if the following versions have been released: 1.0.0, 1.0.1, 1.0.2 and the customer is on version 1.0.1 and reports an issue, the fix must be implemented starting from version 1.0.2 and will be released as part of version 1.0.3 which also includes the changes in release 1.0.2.
This means that the customer will also receive the 1.0.2 changes, besides the requested changes from 1.0.3.
Because of this limitation, SwatFlow requires that any changes done in a hotfix must be absolutely necessary.
They should provide fixes to existing issues and not introduce new features.
If this principle is respected, then regardless if a customer receives more hotfixes than requested, they will only receive fixes to existing issues reported by them or other customers.