You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My initial reaction is that force-pushing tags is kind of heretical because tags are supposed to point to a fix commit, forever and would prefer using plain version numbers. But I cannot articulate any reason why that's better functionally vs just having a moving stable tag.
For a system (or library) that actively supports non-latest versions, having version-tagged documentation makes sense. We really don't. All else being equal, I favor keeping the documentation-publishing process as simple as possible, which I think argues for a stable tag versus everything else.
Over on the web repos we use date-based tags like 2024.12.02, with a suffix like -2 if there is more than one deploy in a day.
A deployment-based semantic could make sense here as well; it would decouple the notion of "stable documentation" explicitly from a release version, but allow us to keep track of when stable deploys took place using git.
Describe the change
In this repository we promote docs to stable by pushing a new versioned tag. In the workstation-docs repository we force-push a "stable" tag.
@nathandyer suggested that we should standardize on one scheme.
The text was updated successfully, but these errors were encountered: