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
Copy file name to clipboardExpand all lines: README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -87,7 +87,7 @@ To create a new public build of DocForge:
87
87
3. Review the Markdown documentation (README, manuals, and release notes) so the written guidance matches the current workflow.
88
88
4. Sync the documentation copies under `docs/` (README, manuals, version log) with any updates made at the project root.
89
89
5. Commit the changes and push them to the default branch so the release tag points at the finalized documentation.
90
-
6. Create and push a tag that matches the new version (for example, `git tag v0.6.8` followed by `git push origin v0.6.8`) to trigger the automated release workflow.
90
+
6. Create and push a tag that matches the new version (for example, `git tag v0.6.9` followed by `git push origin v0.6.9`) to trigger the automated release workflow.
91
91
7. Monitor the "Release" workflow run, then confirm that the published GitHub release lists the correct notes and includes installers for every platform before announcing availability.
Copy file name to clipboardExpand all lines: TECHNICAL_MANUAL.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -145,7 +145,7 @@ Electron Builder manages the packaging and publishing workflow for DocForge. The
145
145
3. Review and update the Markdown documentation (README, manuals, release notes) so the written guidance reflects the final state of the build.
146
146
4. Sync the Markdown files under `docs/` with the copies at the project root.
147
147
5. Commit and push the changes so the release tag points at the finished documentation.
148
-
6. Create and push a matching version tag (for example, `git tag v0.6.8` followed by `git push origin v0.6.8`) to trigger the automated release pipeline.
148
+
6. Create and push a matching version tag (for example, `git tag v0.6.9` followed by `git push origin v0.6.9`) to trigger the automated release pipeline.
149
149
7. Monitor the "Release" workflow run and verify the published GitHub release lists the correct notes and includes the installers for every supported platform before announcing availability.
Copy file name to clipboardExpand all lines: VERSION_LOG.md
+10Lines changed: 10 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,15 @@
1
1
# Version Log
2
2
3
+
## v0.6.9 - The Release Prep Maintenance
4
+
5
+
### 🐛 Fixes
6
+
7
+
- Updated the release workflow fixtures to validate the `v0.6.9` tag and installers, keeping the automated publishing checks aligned with the shipped binaries.
8
+
9
+
### 📝 Documentation
10
+
11
+
- Refreshed the release preparation guides so every README and manual references the `v0.6.9` tagging flow and synchronized documentation updates.
Copy file name to clipboardExpand all lines: docs/README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -85,7 +85,7 @@ To create a new public build of DocForge:
85
85
3. Review the Markdown documentation (README, manuals, and release notes) so the written guidance matches the current workflow.
86
86
4. Sync the documentation copies under `docs/` (README, manuals, version log) with any updates made at the project root.
87
87
5. Commit the changes and push them to the default branch so the release tag points at the finalized documentation.
88
-
6. Create and push a tag that matches the new version (for example, `git tag v0.6.8` followed by `git push origin v0.6.8`) to trigger the automated release workflow.
88
+
6. Create and push a tag that matches the new version (for example, `git tag v0.6.9` followed by `git push origin v0.6.9`) to trigger the automated release workflow.
89
89
7. Monitor the "Release" workflow run, then confirm that the published GitHub release lists the correct notes and includes installers for every platform before announcing availability.
Copy file name to clipboardExpand all lines: docs/TECHNICAL_MANUAL.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -145,7 +145,7 @@ Electron Builder manages the packaging and publishing workflow for DocForge. The
145
145
3. Review and update the Markdown documentation (README, manuals, release notes) so the written guidance reflects the final state of the build.
146
146
4. Sync the Markdown files under `docs/` with the copies at the project root.
147
147
5. Commit and push the changes so the release tag points at the finished documentation.
148
-
6. Create and push a matching version tag (for example, `git tag v0.6.8` followed by `git push origin v0.6.8`) to trigger the automated release pipeline.
148
+
6. Create and push a matching version tag (for example, `git tag v0.6.9` followed by `git push origin v0.6.9`) to trigger the automated release pipeline.
149
149
7. Monitor the "Release" workflow run and verify the published GitHub release lists the correct notes and includes the installers for every supported platform before announcing availability.
Copy file name to clipboardExpand all lines: docs/VERSION_LOG.md
+10Lines changed: 10 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,15 @@
1
1
# Version Log
2
2
3
+
## v0.6.9 - The Release Prep Maintenance
4
+
5
+
### 🐛 Fixes
6
+
7
+
- Updated the release workflow fixtures to validate the `v0.6.9` tag and installers, keeping the automated publishing checks aligned with the shipped binaries.
8
+
9
+
### 📝 Documentation
10
+
11
+
- Refreshed the release preparation guides so every README and manual references the `v0.6.9` tagging flow and synchronized documentation updates.
0 commit comments