1.1.81 update delayed?

[github2023-blip]

The latest (experimental) version (1.1.81) has been released on 2023-04-19: https://forums.factorio.com/105959 Any estimates, when this docker image will be updated? Or are only stable releases considered?

According to https://github.com/factoriotools/factorio-docker/issues/459 there have been issues in the past, are they still persisting?

Many thanks for any information.

[Fank]

Last Check says 1.1.80 is latest https://github.com/factoriotools/factorio-docker/actions/runs/4894935353/jobs/8739828217

[Fank]

Will once back at home

[github2023-blip]

Wow, thank you for the very swift reply and the link to the github action.

From https://github.com/factoriotools/factorio-docker/blob/master/update.sh it is clear now, that only the stable version is checked. curl 'https://www.factorio.com/updater/get-available-versions?apiVersion=2' | jq '.[] | .[] | select(.stable) | .stable' -r

So I assume we just have to wait, until 1.1.81 gets stable.

Is it on purpose to use the stable version? I suppose it would be trivial to switch to experimental version with something like curl 'https://factorio.com/api/latest-releases' | jq '.experimental.headless' -r (and further changes down the line, e.g. https://github.com/factoriotools/factorio-docker/blob/master/update.sh#L6).

[Fank]

Hm I think that restriction was not on purpose, @KagurazakaNyaa could you bring some insights here?

To extend the check for experimental, could you create an PR for it?

[KagurazakaNyaa]

Wow, thank you for the very swift reply and the link to the github action.

From https://github.com/factoriotools/factorio-docker/blob/master/update.sh it is clear now, that only the stable version is checked. curl 'https://www.factorio.com/updater/get-available-versions?apiVersion=2' | jq '.[] | .[] | select(.stable) | .stable' -r

So I assume we just have to wait, until 1.1.81 gets stable.

Is it on purpose to use the stable version? I suppose it would be trivial to switch to experimental version with something like curl 'https://factorio.com/api/latest-releases' | jq '.experimental.headless' -r (and further changes down the line, e.g. https://github.com/factoriotools/factorio-docker/blob/master/update.sh#L6).

I'm trying to use this API to rewrite the update check script. What I want to know is, when there is no experimental release, will the content of experimental be consistent with stable or will there be no such element?

[KagurazakaNyaa]

Hm I think that restriction was not on purpose, @KagurazakaNyaa could you bring some insights here?

To extend the check for experimental, could you create an PR for it?

I will now first rewrite the check script based on the assumption that if there is no experimental release, this API returns the assumption that the experimental still exists and the content is the same as stable. But when 1.1.81 becomes a stable version, it may be necessary to check whether the actual situation is the same as the assumption.

[github2023-blip]

Hi @KagurazakaNyaa thanks for chiming in! Please somebody correct me if I am wrong, but I think Wube always pushes new versions to experimental branch first. And then eventually (after 2 months or so?) the experimental branch will get stable. So, the experimental version should always be either higher than the stable version or the same.

Does this answer your questions?

[Fank]

We should always create tags for each version, regardless if stable or experimental. With the old watchdog we marked stable as stable and experimental as latest, as you can see here https://github.com/factoriotools/factorio-docker/tree/5bf1b045e1cf1254acdf9be2bde7aa17b18b36c6

[KagurazakaNyaa]

We should always create tags for each version, regardless if stable or experimental. With the old watchdog we marked stable as stable and experimental as latest, as you can see here https://github.com/factoriotools/factorio-docker/tree/5bf1b045e1cf1254acdf9be2bde7aa17b18b36c6

Here is a question, should 1 and 1.1 tags follow stable instead of latest? Because the client is updated to the stable version by default, unless it is manually configured to participate in the beta version on steam. So I think the use of the experimental version should be manual rather than the default behavior. Maybe it is better behavior to follow the stable tag with the major version number (1) and the short version number (1.1), while the latest tag should only be followed by the full version number (1.1.81)

So, maybe we can consider this tag combination

• 1.1.81, latest
• 1, 1.1, 1.1.80, stable

Or we keep the previous behavior and let these tags follow the experimental version, then the combination should look like this

• 1, 1.1, 1.1.81, latest
• 1.1.80, stable

But this will cause a problem, that is, if the main version number or short version number is used to fix the version, it may lead to unexpected use of the experimental version instead of the stable version. Both approaches do make sense, but I personally prefer to follow stable because its behavior is closer to the client's update strategy.

[Fank]

So, maybe we can consider this tag combination

• 1.1.81, latest
• 1, 1.1, 1.1.80, stable

Based on your arguments i can recommend using that as well, because the semantiv version used in docker in general always points to a stable version and not to a dev/night/beta build. So if you want to use a experimental version, then use the latest tag or pin it with a version.

[github2023-blip]

I just want to say thank you, this seems to work just fine now :)