We use Semantic Versioning for each component.
Which provides more transparency for developers about what work is required to update than a single major version for all components:
Major Incompatible changes — Requires changes to implement, like updates to HTML, class names
Minor Backwards-compatible features — Features that don’t require much/or any implementation.
Patch backwards-compatible bug fix — Fixed something with doesn’t require implementation
We also want to step away from the whole “UI-Kit v3” concept and move to something more iterative. Where value is delivered more often in smaller pieces and teams can choose which updates to use, rather being required to update everything all at once.
As an example if Core gets a new Major version (incompatible changes) all components would be bumped up a Major version anyway because they have a dependency on it and some effort would be required to update.
So in direct answer to your question: If we have Animate.1.0.4 and Header.4.1.1, and both are the latest version; then neither of them are ‘out-of-date’… If we then discovered an accessibility bug in Header which requires a HTML change to fix, it would be bumped to Header.5.1.1, so that anyone looking to use the latest version of Header can quickly see some work is required to adopt it.
One UI-Kit changelog page
I think that is a good idea! So that progress as a whole is easier to track.
(CC: @patrick @alex.page)