Hacker News Reader

Comment by iruoy | Hacker News Reader

I couldn't even install this on my server because it has Node 18 instead of 16

If you're trying to run more than one application on a server you probably ought to install dependencies in such a way that different applications can use different versions. Either using a toolchain-specific version manager such as nodenv (or nvm or asdf), or a more general tool like Docker.

It's pretty reasonable for projects to require a specific language version. Especially in this case as 16 is still the latest LTS version of Node.js.

EDIT: They even say "Ghost can work with other operating systems, node versions, and databases (particularly those supported by Knex) - but as a small team, we only document and support one narrow stack that we know works really well."

Can't really see how you can fault that.

This is not a production server. Just something I'm running for personal services.

And I would expect a new major release to run on the latest even version of nodejs. The uneven versions are for development purposes. Version 18 will become the active LTS in a few months.

Then we will support it in a few months. That's how LTS works. We can't just add support for Node 18 if all the upstream packages we depend on don't support Node 18.

What a time we live in where you don't have to worry about running software because your OS is too old, or you don't have a Pentium 2, or enough RAM. If they document their requirements and you can't meet them, then the software isn't for you right now. That's not really their fault.

they provide ready to be deployed Docker images

https://hub.docker.com/_/ghost/

Although, to throw some historically anecdotal salt into the fire, I was kinda forced to switch from Ghost to Hugo when firstly, the migration to v1.0 (late 2017) using the Docker images was a right old faff and secondly, a few months later (early 2018), said Docker image managed to wedge itself into an inoperable mess.

> said Docker image managed to wedge itself into an inoperable mess

Can you elaborate on the issue you encountered?

Most issues I've seen in the wild related to docker deployments is due to not specifying a version tag on the docker image, which means docker will pull the image with the `latest` tag. Fast forward a few years, when you need to restart the container, and for some reason you pull the `latest` image again (either accidentally or automatically by your container system), the new version is now too far ahead from your previous system and break spectacularly when run with your existing data. Some apps even attempt to migrate the data, but failed and leave the data in corrupted state so you can't go back to the previous version.

> Can you elaborate on the issue you encountered?

Alas, no, I didn't keep detailed notes at the time (2018) because I was too busy trying to recover my blog from the disaster.

> Fast forward a few years [...] the new version is now too far ahead

It was 6 months after the migration to v1 and 5 months before v2 came out.

yeah, but just like with everything else you self-host - requires maintenance

Reply on news.ycombinator.com