The author correctly recognizes why readers might care about when a blog was updated at the beginning:
Blogs aren’t static documents - they’re living entities that evolve over time. A finance blog might need to revise outdated market advice, while a science blog must keep pace with new research findings. Technical tutorials require updates as software versions change, and even the most carefully curated resource lists eventually face broken links. Beyond these obvious changes, there’s the constant refinement of writing, the clarification of thoughts, and the improvement of explanations.
But then the author seems to forget about those goals entirely and devises a system that doesn’t satisfy any of the original goals:
For example the version number v24.628.M.2111 tells me that:
The blog was last updated in 2024.
There have been 628 updates so far this year.
The most recent update involved multiple changes on November 21st.
Readers are interested in freshness at the article level. If I’m reading an article about React, I’d like to know that it was written or updated in the last two years. I don’t care that some change was made somewhere on the blog last week, as it says nothing about the article I’m reading.
If the author wants a way to track their blog’s version for their own purpose, that’s fine, but they should just use Hugo’s hugo.IsServer mechanism so that the version string renders for them locally but does not appear on the page for real readers, for whom the version string is meaningless noise.
Coming to the overall versioning, I think it’s just a personal preference! I personally love to see what micro changes people have done to their blogs!
There are three conceptual areas a blog can change—the underlying engine, the style (or UI) of the blog, and the actual entries themselves. For my blog [1] the engine is at a (more or less arbitrary) version of 63 [2]. I haven’t versioned the style of my blog, since it really hasn’t changed all that much since 1999, but there have been a lot of small tweaks to it since I slapped the template into git back in December of 2009 (or November 2011 when I put the CSS under git). As for the entries, all entries are dated, and if there’s an update, I’ll give the date of the update.
[1] Which I started in December 1999.
[2] Which isn’t indicative of its actual version. I lost the history of the project prior to May 2009 when I lost the CVS repository to a computer crash. The current version of 63 reflects the number of releases since I started using git.
My posts have a date and if I ever update them they get an “Update YYYY/MM(/DD)” prefix to a paragraph - this has worked out for literal decades, but then again I don’t write highly technical howtos that simply go out of date in 2 years - it very much depends on the content.
As a reader, I don’t often care about the change history of an entire blog, but I do care about when a specific article was last updated. In fact, I care about exactly two things: when the article was first published and when it was last updated. These two details are usually sufficient. A detailed change history for the article would be a nice bonus but not essential. From reading this article, it seems like you are focusing more on the blog-level change history. Is that right?
That being said, it’s your blog, and you should feel free to tweak, change, and update it however you see fit! Everyone has their own approach, and there’s no one-size-fits-all when it comes to maintaining a blog.
Personally, I have my blog rendered using a Common Lisp program I wrote myself. While I don’t tweak it as often, I do support a mandatory publication date and an optional update date for posts. When a post undergoes too many updates, I prefer to write the change history manually at the bottom of the article in the following format:
Update on DD Month YYYY: [followed by what was updated]
It is a simple, low-tech approach, but it works for me.
Yes I’m focusing on the blog level change. Also in my opinion version number has nothing do with the end consumer and is for more the devs. Coming to this implementation, I love tweaking stuff on my blog, I’m a relatively new programmer and thought of doing it as a fun project. I also wanted to add a small change log for each page and thus the main log acts as a base for it. I haven’t implemented it yet!
P.S: I’m not sure why I’m receiving lot of hate comments for this article on my blog. The traffic has been predominantly from Lobsters. Did I write something to upset the community?
Thanks for the clarification. Yes, it does make sense to have a blog-level version number for the devs.
About your postscript remark, I can’t speak for the whole community but I found your post interesting. The 7 upvotes right now indicate that at least 5 others found it interesting too.
I have a detailed changelog of the content in my Django-powered blog using a variant of my Git scraping pattern: once every two hours a script in this GitHub repo https://github.com/simonw/simonwillisonblog-backup pulls a copy of my PostgreSQL database and flattens it into newline-delimited JSON in that repo, then commits any changes.
It’s not particularly usable for other people, but if I ever want to check when I made a particular change to an item on my blog I can find it in that commit history.
The author correctly recognizes why readers might care about when a blog was updated at the beginning:
But then the author seems to forget about those goals entirely and devises a system that doesn’t satisfy any of the original goals:
Readers are interested in freshness at the article level. If I’m reading an article about React, I’d like to know that it was written or updated in the last two years. I don’t care that some change was made somewhere on the blog last week, as it says nothing about the article I’m reading.
If the author wants a way to track their blog’s version for their own purpose, that’s fine, but they should just use Hugo’s
hugo.IsServermechanism so that the version string renders for them locally but does not appear on the page for real readers, for whom the version string is meaningless noise.Thanks for your feedback!
The goal for this versioning system and the log was to generate a changelog for each blog post using the master log data. Example to an implementation: https://annualbeta.com/blog/a-changelog-for-my-blog-posts/
Coming to the overall versioning, I think it’s just a personal preference! I personally love to see what micro changes people have done to their blogs!
There are three conceptual areas a blog can change—the underlying engine, the style (or UI) of the blog, and the actual entries themselves. For my blog [1] the engine is at a (more or less arbitrary) version of 63 [2]. I haven’t versioned the style of my blog, since it really hasn’t changed all that much since 1999, but there have been a lot of small tweaks to it since I slapped the template into
gitback in December of 2009 (or November 2011 when I put the CSS undergit). As for the entries, all entries are dated, and if there’s an update, I’ll give the date of the update.[1] Which I started in December 1999.
[2] Which isn’t indicative of its actual version. I lost the history of the project prior to May 2009 when I lost the CVS repository to a computer crash. The current version of 63 reflects the number of releases since I started using
git.My posts have a date and if I ever update them they get an “Update YYYY/MM(/DD)” prefix to a paragraph - this has worked out for literal decades, but then again I don’t write highly technical howtos that simply go out of date in 2 years - it very much depends on the content.
As a reader, I don’t often care about the change history of an entire blog, but I do care about when a specific article was last updated. In fact, I care about exactly two things: when the article was first published and when it was last updated. These two details are usually sufficient. A detailed change history for the article would be a nice bonus but not essential. From reading this article, it seems like you are focusing more on the blog-level change history. Is that right?
That being said, it’s your blog, and you should feel free to tweak, change, and update it however you see fit! Everyone has their own approach, and there’s no one-size-fits-all when it comes to maintaining a blog.
Personally, I have my blog rendered using a Common Lisp program I wrote myself. While I don’t tweak it as often, I do support a mandatory publication date and an optional update date for posts. When a post undergoes too many updates, I prefer to write the change history manually at the bottom of the article in the following format:
It is a simple, low-tech approach, but it works for me.
Yes I’m focusing on the blog level change. Also in my opinion version number has nothing do with the end consumer and is for more the devs. Coming to this implementation, I love tweaking stuff on my blog, I’m a relatively new programmer and thought of doing it as a fun project. I also wanted to add a small change log for each page and thus the main log acts as a base for it. I haven’t implemented it yet!
P.S: I’m not sure why I’m receiving lot of hate comments for this article on my blog. The traffic has been predominantly from Lobsters. Did I write something to upset the community?
Thanks for the clarification. Yes, it does make sense to have a blog-level version number for the devs.
About your postscript remark, I can’t speak for the whole community but I found your post interesting. The 7 upvotes right now indicate that at least 5 others found it interesting too.
I have a detailed changelog of the content in my Django-powered blog using a variant of my Git scraping pattern: once every two hours a script in this GitHub repo https://github.com/simonw/simonwillisonblog-backup pulls a copy of my PostgreSQL database and flattens it into newline-delimited JSON in that repo, then commits any changes.
It’s not particularly usable for other people, but if I ever want to check when I made a particular change to an item on my blog I can find it in that commit history.
And, it’s free.
I like this idea, even if only for creating a proper changelog.