It helps stakeholders to maintain a list of releases (past, current and planned). It may tell them that they should read up on the current design – for example in the interfaces chapter if they are working on a system that integrates with this solution.
The release list also gives an indication of how where an ongoing development project is on its journey to deliver the final solution, and hence how sketchy or complete the architecture documentation can be expected to be.
In early development stages I list minor internal releases to keep the team informed of our small iterative achievements, but I usually remove all those releases when the project has released the first major version of the solution.
If you choose to publish a baselined solution architecture document with each release, you can add a column with links to each published document version.
I rarely find this necessary for minor releases, but do so fairly often when releasing new versions as part of solution maintenance work. And sometimes a just list past solution architecture document versions in the references chapter.
I recommend that this chapter contains a table with the following columns:
|v0.1||2020-04-18||PoC to verify the development environment and chosen technologies.|
|v0.2||2020-05-10||PoC to verify key design decisions.|
|v1.0||TBD||First public release (planned).|