feat: update version to 0.6.2. added Action to update pyproject on Release

[tobitege]

What is the problem that this fixes or functionality that this introduces? Does it fix any open issues?

• PR updates the pyproject.toml version from 0.1.0 to 0.6.2.

• Added new GitHub Action "update-pyproject-version.yml" to run on Release creation: this will read the used Tag, write it to the pyproject.toml file, commit it. Then the continuing Release process will have this updated version in pyproject.

Give a brief summary of what the PR does, explaining any non-trivial design decisions

Automatic version updating.

[tobitege]

Updated workflow with the help of Sonnet 3.5 😀 :

1. It installs the required dependencies (toml and semver) for version comparison.
2. It fetches both the latest tag and the current pyproject.toml version.
3. It compares the versions using the semver library to determine the appropriate action:
   If pyproject version > latest tag: create a new tag
   If pyproject version < latest tag: update pyproject.toml
   If versions are equal: do nothing
4. Based on the comparison result, it either updates the pyproject.toml file or creates a new tag.
   This workflow will now handle both scenarios: updating pyproject.toml when a higher tag exists, and creating a new tag when the pyproject.toml version is higher than the current tag.

[li-boxuan]

I don't feel like I am the right one to review this, since I am not familiar with the current release procedure of OpenDevin.
That being said, I do have a question: Instead of having a CI to compare and fix discrepancies between pyproject version and tags, how about create a CI (triggered manually) that actually does the release (including but not limited to updating pyproject version and tags)?

[tobitege]

I don't feel like I am the right one to review this, since I am not familiar with the current release procedure of OpenDevin. That being said, I do have a question: Instead of having a CI to compare and fix discrepancies between pyproject version and tags, how about create a CI (triggered manually) that actually does the release (including but not limited to updating pyproject version and tags)?

Sure, whatever fits the requirements. The idea just appealed to me to keep both places in sync.

I just noticed: @xingyaoww as you did the 0.6.2 release, you have any thoughts if/how this could be usable?

[xingyaoww]

I think if we can get this working automatically, this is certainly preferable (it is easy to forget...) -- Maybe the action can automatically submit a PR with version changes once a release is cut (e.g., similar to what we got with dependabot?), and we can manually approve and merge it?

[tobitege]

I think if we can get this working automatically, this is certainly preferable (it is easy to forget...) -- Maybe the action can automatically submit a PR with version changes once a release is cut (e.g., similar to what we got with dependabot?), and we can manually approve and merge it?

That sounds interesting, it's just not my expertise and I'm a bit hesitant about making backend changes on GH.
Can you provide me a hint what was used last time for the release?

[xingyaoww]

@tobitege Here's the instruction i got for cutting a release: https://opendevin.slack.com/archives/C06U8UTKSAD/p1717611818024469?thread_ts=1717610621.451799&cid=C06U8UTKSAD

It was quite simple and straight forward i guess?

[tobitege]

@tobitege Here's the instruction i got for cutting a release: https://opendevin.slack.com/archives/C06U8UTKSAD/p1717611818024469?thread_ts=1717610621.451799&cid=C06U8UTKSAD

It was quite simple and straight forward i guess?

Oh, if that's the case (just read the slack convo), then I know what to look for. That helped a lot, thanks so much!

[Shimada666]

@tobitege
I understand the release process now. 😁 Tags are created manually, Then the release person can create the release from the tag.
Maybe my script can give some help, it can update the version and create the tag.

#!/bin/bash

# You can input "patch", "minor", "major", or a specific version like "0.6.3".
poetry version $1

# Get new version number
NEW_VERSION=$(poetry version -s)

# commit and create tag
git add pyproject.toml
git commit -m "Bump version to $NEW_VERSION"
git tag "$NEW_VERSION" 

Use it:

./bump_version.sh patch  # or minor/major/0.6.3

Then, the release person just needs to check it and, if everything is fine, submit it.

# then check and push it manually
git push --tags

[tobitege]

@tobitege I understand the release process now. 😁 Tags are created manually, Then the release person can create the release from the tag. Maybe my script can give some help, it can update the version and create the tag.

Actually my yml should do that already, it is only a matter of getting triggered by the right backend action, like the tag creation (and only that). No manual commits etc. 😃

[tobitege]

Simplified the action to only be triggered by a Release, i.e. after a tag was chosen.
This action will now read the used Tag, write it to the pyproject.toml file, commit it.
Thus after this, the continuing Release process will have this updated version in pyproject.
cc @xingyaoww

[xingyaoww]

LGTM!