[Feature]: Auto-update docs when a new release is cut

[neubig]

What problem or use case are you trying to solve?

Currently our docs show an old version number (0.3.1) as recommended to be installed, despite the fact that a newer version is available (0.4.1).

Describe the UX of the solution you'd like

It would be nice if this number was auto-updated with the most recent version tag on github.

[iFurySt]

can we just replace the tag with the latest? 🤔

[neubig]

Does that work? If so, that'd be great.

[iFurySt]

we just need to add the --pull always, it will only pull when the image doesn't exist locally or the digest is different.

[neubig]

Awesome, if you could send a PR updating the docs appropriately (I'm not sure I'd get it right), I can close mine here: https://github.com/OpenDevin/OpenDevin/pull/1546

[iFurySt]

okay, let me submit a PR.

[iFurySt]

@rbren i saw you deleted the latest tag from the containers/build.sh. what is the reason?

[rbren]

latest is never a good idea 😄 it tends to be whatever was last pushed to the repo--including dev branches.

@Sparkier suggested a release tag, which is better--then at least we're saying "we've done a bit of QA on this, and it's ready for end users". There's also a main tag, for users who want the bleeding edge.

But I much prefer having semver here. E.g. we are about to release 0.5.0, which requires changes to the docker run command. If we were just cutting it as release, we'd break people's existing docker run commands, with zero notice.

I realize it's a pain to have to update the docs every time we cut a new version, but there's actually a good reason for it--it prevents breaking changes from leaking out unintentionally. It's a perpetual problem with widely-used software 😄

The best middleground here is to release all semver tags. So when we git tag 0.5.0, it will release three tags:

• 0.5.0
• 0.5
• 0

And then when we git tag 0.5.1, it will create a new 0.5.1 tag, and overwrite the 0.5 and 0 tags.

The docs in my PR for the 0.5.0 update will reference 0.5, so that we can release patch changes without having to go back to the docs. If we make a breaking change, we'll release 0.6, and update the docs accordingly.

Hopefully that makes sense 😄 this is a problem I've dealt with extensively in other projects

[neubig]

This makes sense!

[rbren]

I do think it'd be neat for the git tag workflow to open up a PR with the required docs changes!

[yufansong]

The docs https://github.com/OpenDevin/OpenDevin/pull/1523 will reference 0.5, so that we can release patch changes without having to go back to the docs. If we make a breaking change, we'll release 0.6, and update the docs accordingly.

Some suggestions about our version release. I always follow this rule: https://semver.org/

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[neubig]

Closing as unplanned due to complexity.