vieter-0.5.0: final read

content/posts/vieter-0.5.0/index.md

@@ -1,10 +1,10 @@
 ---
 title: "Announcing Vieter 0.5.0"
 date: 2022-12-29
-draft: true
 ---
 
-As 2022 comes to a close, I'm ready to release another version of Vieter!
+As 2022 comes to a close, and in the middle of exams, I'm ready to release
+another version of Vieter!
 
 ## What's Vieter?
 
@@ -67,11 +67,11 @@ in the coming months.
 For starters: better build awareness. The build system right now does not track
 the progress of jobs. Once a job is dispatched to an agent, the main server
 forgets about it and moves on. If a build fails due to unknown means causing
-the log to never be uploaded, it'll be as if the build never happened. I'd like
-to change this. I want the main server to be aware of what jobs are running,
-have failed, or have perhaps timed out. This information could then be made
-available through the API, providing the user with valuable insight into the
-workings of their Vieter instance.
+the logs to never be uploaded, it'll be as if the build never happened. I'd
+like to change this. I want the main server to be aware of what jobs are
+running, have failed, or have perhaps timed out. This information could then be
+made available through the API, providing the user with valuable insight into
+the workings of their Vieter instance.
 
 Building on this idea, I wish to know what specific command caused the build to
 fail. Was it makepkg, an HTTP error? And if it was makepkg, what error code?
@@ -82,7 +82,7 @@ whole.
 Another big one to tackle is API access to the repositories. These are
 currently only accessible through Pacman, but having this information available
 as a convenient REST API, useable from the CLI tool, sounds like a valuable
-asset. This would pave the road towards repository-level configuration.
+asset. This would pave the way towards repository-level configuration.
 
 Of course there's a lot more ideas, but the list would be too long to put here
 ;p