chore: introduce towncrier

[0xRAG]

What changed?

This PR introduces towncrier to manage the AgentKit.py changelogs. While towncrier can support a monorepo setup, we currently do not treat the Python packages as a monorepo, so I decided to introduce towncrier to each Python package individually.

The following towncrierconfig options are modified:

filename = "CHANGELOG.md"# What we currently usedirectory = "changelog.d/"# Standard used by some open source Python projects
[tool.towncrier.fragment.feature]
name = "Added"# To align with our current changelog format
[tool.towncrier.fragment.bugfix]
name = "Fixed"# To align with our current changelog format

Why?

Contributors can add independent changelog entries without having to worry about or deal with merge conflicts.

Maintainers can generate full changelogs with one command.

The intended contribution workflow is:

• Developer makes a change to some code in a package
• Developer runs poetry run towncrier create from the package folder with appropriate options to write a changelog entry
• Developer checks in generated entry with their PR
• Maintainer reviews the generated entry for version type and change content. Version type should be feature or bugfix (these are two of towncriers default types, and change content should be in past tense (e.g. "Added new feature", "Fixed the bug")

The release workflow is:

• Maintainer runs poetry run towncrier which will consume changelog entries in .changelog.d/ and append to the CHANGELOG.md
• Maintainer reviews the generated CHANGELOG.md for formatting and makes any changes necessary (for example adding a date to the release log line, if not present)
• Maintainer bumps versions in the same way as they are done today
• Maintainer opens PR with the result from above
• Once merged, packages are released as they are today, using existing GitHub Actions

Next steps

• Investigate tools similar changesets bot to automatically request contributors add a changeset

[CarsonRoscoe]

Functionally and README wise, this LGTM, I am happy with this.

My one (minor) concern I want to raise is that towncrier has the user write the changelog info in vim. I think this is fine, if a user is technical enough to be contributing they should know how to i -> [type changes] -> esc:wq. But we need to acknowledge that we are adding a little bit of onboarding friction to contributors.

The base branch was changed.

[cb-heimdall]

✅ Heimdall Review Status

Requirement	Status	More Info
Reviews	✅ 1/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[0xRAG]

Functionally and README wise, this LGTM, I am happy with this.

My one (minor) concern I want to raise is that towncrier has the user write the changelog info in vim. I think this is fine, if a user is technical enough to be contributing they should know how to i -> [type changes] -> esc:wq. But we need to acknowledge that we are adding a little bit of onboarding friction to contributors.

That's a good point, and depends on how the user initiates towncrier. If they follow the guide in the contributing, they won't have to enter vim, as they will specify the changelog in a command line argument. Will keep an eye on this

[CarsonRoscoe]

LGTM

[0xRAG]

What changed?

This PR introduces towncrier to manage the AgentKit.py changelogs. While towncrier can support a monorepo setup, we currently do not treat the Python packages as a monorepo, so I decided to introduce towncrier to each Python package individually.

The following towncrierconfig options are modified:

filename = "CHANGELOG.md"# What we currently usedirectory = "changelog.d/"# Standard used by some open source Python projects
[tool.towncrier.fragment.feature]
name = "Added"# To align with our current changelog format
[tool.towncrier.fragment.bugfix]
name = "Fixed"# To align with our current changelog format

Why?

Contributors can add independent changelog entries without having to worry about or deal with merge conflicts.

Maintainers can generate full changelogs with one command.

The intended contribution workflow is:

• Developer makes a change to some code in a package
• Developer runs poetry run towncrier create from the package folder with appropriate options to write a changelog entry
• Developer checks in generated entry with their PR
• Maintainer reviews the generated entry for version type and change content. Version type should be feature or bugfix (these are two of towncriers default types, and change content should be in past tense (e.g. "Added new feature", "Fixed the bug")

The release workflow is:

• Maintainer runs poetry run towncrier which will consume changelog entries in .changelog.d/ and append to the CHANGELOG.md
• Maintainer reviews the generated CHANGELOG.md for formatting and makes any changes necessary (for example adding a date to the release log line, if not present)
• Maintainer bumps versions in the same way as they are done today
• Maintainer opens PR with the result from above
• Once merged, packages are released as they are today, using existing GitHub Actions

Next steps

• Investigate tools similar changesets bot to automatically request contributors add a changeset

[CarsonRoscoe]

Functionally and README wise, this LGTM, I am happy with this.

My one (minor) concern I want to raise is that towncrier has the user write the changelog info in vim. I think this is fine, if a user is technical enough to be contributing they should know how to i -> [type changes] -> esc:wq. But we need to acknowledge that we are adding a little bit of onboarding friction to contributors.

The base branch was changed.

[cb-heimdall]

✅ Heimdall Review Status

Requirement	Status	More Info
Reviews	✅ 1/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[0xRAG]

Functionally and README wise, this LGTM, I am happy with this.

My one (minor) concern I want to raise is that towncrier has the user write the changelog info in vim. I think this is fine, if a user is technical enough to be contributing they should know how to i -> [type changes] -> esc:wq. But we need to acknowledge that we are adding a little bit of onboarding friction to contributors.

That's a good point, and depends on how the user initiates towncrier. If they follow the guide in the contributing, they won't have to enter vim, as they will specify the changelog in a command line argument. Will keep an eye on this

[CarsonRoscoe]

LGTM

[0xRAG]

What changed?

This PR introduces towncrier to manage the AgentKit.py changelogs. While towncrier can support a monorepo setup, we currently do not treat the Python packages as a monorepo, so I decided to introduce towncrier to each Python package individually.

The following towncrierconfig options are modified:

filename = "CHANGELOG.md"# What we currently usedirectory = "changelog.d/"# Standard used by some open source Python projects
[tool.towncrier.fragment.feature]
name = "Added"# To align with our current changelog format
[tool.towncrier.fragment.bugfix]
name = "Fixed"# To align with our current changelog format

Why?

Contributors can add independent changelog entries without having to worry about or deal with merge conflicts.

Maintainers can generate full changelogs with one command.

The intended contribution workflow is:

• Developer makes a change to some code in a package
• Developer runs poetry run towncrier create from the package folder with appropriate options to write a changelog entry
• Developer checks in generated entry with their PR
• Maintainer reviews the generated entry for version type and change content. Version type should be feature or bugfix (these are two of towncriers default types, and change content should be in past tense (e.g. "Added new feature", "Fixed the bug")

The release workflow is:

• Maintainer runs poetry run towncrier which will consume changelog entries in .changelog.d/ and append to the CHANGELOG.md
• Maintainer reviews the generated CHANGELOG.md for formatting and makes any changes necessary (for example adding a date to the release log line, if not present)
• Maintainer bumps versions in the same way as they are done today
• Maintainer opens PR with the result from above
• Once merged, packages are released as they are today, using existing GitHub Actions

Next steps

• Investigate tools similar changesets bot to automatically request contributors add a changeset

[CarsonRoscoe]

Functionally and README wise, this LGTM, I am happy with this.

My one (minor) concern I want to raise is that towncrier has the user write the changelog info in vim. I think this is fine, if a user is technical enough to be contributing they should know how to i -> [type changes] -> esc:wq. But we need to acknowledge that we are adding a little bit of onboarding friction to contributors.

The base branch was changed.

[cb-heimdall]

✅ Heimdall Review Status

Requirement	Status	More Info
Reviews	✅ 1/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[0xRAG]

Functionally and README wise, this LGTM, I am happy with this.

My one (minor) concern I want to raise is that towncrier has the user write the changelog info in vim. I think this is fine, if a user is technical enough to be contributing they should know how to i -> [type changes] -> esc:wq. But we need to acknowledge that we are adding a little bit of onboarding friction to contributors.

That's a good point, and depends on how the user initiates towncrier. If they follow the guide in the contributing, they won't have to enter vim, as they will specify the changelog in a command line argument. Will keep an eye on this

[CarsonRoscoe]

LGTM

[0xRAG]

What changed?

This PR introduces towncrier to manage the AgentKit.py changelogs. While towncrier can support a monorepo setup, we currently do not treat the Python packages as a monorepo, so I decided to introduce towncrier to each Python package individually.

The following towncrierconfig options are modified:

filename = "CHANGELOG.md"# What we currently usedirectory = "changelog.d/"# Standard used by some open source Python projects
[tool.towncrier.fragment.feature]
name = "Added"# To align with our current changelog format
[tool.towncrier.fragment.bugfix]
name = "Fixed"# To align with our current changelog format

Why?

Contributors can add independent changelog entries without having to worry about or deal with merge conflicts.

Maintainers can generate full changelogs with one command.

The intended contribution workflow is:

• Developer makes a change to some code in a package
• Developer runs poetry run towncrier create from the package folder with appropriate options to write a changelog entry
• Developer checks in generated entry with their PR
• Maintainer reviews the generated entry for version type and change content. Version type should be feature or bugfix (these are two of towncriers default types, and change content should be in past tense (e.g. "Added new feature", "Fixed the bug")

The release workflow is:

• Maintainer runs poetry run towncrier which will consume changelog entries in .changelog.d/ and append to the CHANGELOG.md
• Maintainer reviews the generated CHANGELOG.md for formatting and makes any changes necessary (for example adding a date to the release log line, if not present)
• Maintainer bumps versions in the same way as they are done today
• Maintainer opens PR with the result from above
• Once merged, packages are released as they are today, using existing GitHub Actions

Next steps

• Investigate tools similar changesets bot to automatically request contributors add a changeset

[CarsonRoscoe]

Functionally and README wise, this LGTM, I am happy with this.

My one (minor) concern I want to raise is that towncrier has the user write the changelog info in vim. I think this is fine, if a user is technical enough to be contributing they should know how to i -> [type changes] -> esc:wq. But we need to acknowledge that we are adding a little bit of onboarding friction to contributors.

The base branch was changed.

[cb-heimdall]

✅ Heimdall Review Status

Requirement	Status	More Info
Reviews	✅ 1/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[0xRAG]

Functionally and README wise, this LGTM, I am happy with this.

My one (minor) concern I want to raise is that towncrier has the user write the changelog info in vim. I think this is fine, if a user is technical enough to be contributing they should know how to i -> [type changes] -> esc:wq. But we need to acknowledge that we are adding a little bit of onboarding friction to contributors.

That's a good point, and depends on how the user initiates towncrier. If they follow the guide in the contributing, they won't have to enter vim, as they will specify the changelog in a command line argument. Will keep an eye on this

[CarsonRoscoe]

LGTM

[0xRAG]

What changed?

This PR introduces towncrier to manage the AgentKit.py changelogs. While towncrier can support a monorepo setup, we currently do not treat the Python packages as a monorepo, so I decided to introduce towncrier to each Python package individually.

The following towncrierconfig options are modified:

filename = "CHANGELOG.md"# What we currently usedirectory = "changelog.d/"# Standard used by some open source Python projects
[tool.towncrier.fragment.feature]
name = "Added"# To align with our current changelog format
[tool.towncrier.fragment.bugfix]
name = "Fixed"# To align with our current changelog format

Why?

Contributors can add independent changelog entries without having to worry about or deal with merge conflicts.

Maintainers can generate full changelogs with one command.

The intended contribution workflow is:

• Developer makes a change to some code in a package
• Developer runs poetry run towncrier create from the package folder with appropriate options to write a changelog entry
• Developer checks in generated entry with their PR
• Maintainer reviews the generated entry for version type and change content. Version type should be feature or bugfix (these are two of towncriers default types, and change content should be in past tense (e.g. "Added new feature", "Fixed the bug")

The release workflow is:

• Maintainer runs poetry run towncrier which will consume changelog entries in .changelog.d/ and append to the CHANGELOG.md
• Maintainer reviews the generated CHANGELOG.md for formatting and makes any changes necessary (for example adding a date to the release log line, if not present)
• Maintainer bumps versions in the same way as they are done today
• Maintainer opens PR with the result from above
• Once merged, packages are released as they are today, using existing GitHub Actions

Next steps

• Investigate tools similar changesets bot to automatically request contributors add a changeset

[CarsonRoscoe]

Functionally and README wise, this LGTM, I am happy with this.

My one (minor) concern I want to raise is that towncrier has the user write the changelog info in vim. I think this is fine, if a user is technical enough to be contributing they should know how to i -> [type changes] -> esc:wq. But we need to acknowledge that we are adding a little bit of onboarding friction to contributors.

The base branch was changed.

[cb-heimdall]

✅ Heimdall Review Status

Requirement	Status	More Info
Reviews	✅ 1/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[0xRAG]

Functionally and README wise, this LGTM, I am happy with this.

My one (minor) concern I want to raise is that towncrier has the user write the changelog info in vim. I think this is fine, if a user is technical enough to be contributing they should know how to i -> [type changes] -> esc:wq. But we need to acknowledge that we are adding a little bit of onboarding friction to contributors.

That's a good point, and depends on how the user initiates towncrier. If they follow the guide in the contributing, they won't have to enter vim, as they will specify the changelog in a command line argument. Will keep an eye on this

[CarsonRoscoe]

LGTM

[0xRAG]

What changed?

This PR introduces towncrier to manage the AgentKit.py changelogs. While towncrier can support a monorepo setup, we currently do not treat the Python packages as a monorepo, so I decided to introduce towncrier to each Python package individually.

The following towncrierconfig options are modified:

filename = "CHANGELOG.md"# What we currently usedirectory = "changelog.d/"# Standard used by some open source Python projects
[tool.towncrier.fragment.feature]
name = "Added"# To align with our current changelog format
[tool.towncrier.fragment.bugfix]
name = "Fixed"# To align with our current changelog format

Why?

Contributors can add independent changelog entries without having to worry about or deal with merge conflicts.

Maintainers can generate full changelogs with one command.

The intended contribution workflow is:

• Developer makes a change to some code in a package
• Developer runs poetry run towncrier create from the package folder with appropriate options to write a changelog entry
• Developer checks in generated entry with their PR
• Maintainer reviews the generated entry for version type and change content. Version type should be feature or bugfix (these are two of towncriers default types, and change content should be in past tense (e.g. "Added new feature", "Fixed the bug")

The release workflow is:

• Maintainer runs poetry run towncrier which will consume changelog entries in .changelog.d/ and append to the CHANGELOG.md
• Maintainer reviews the generated CHANGELOG.md for formatting and makes any changes necessary (for example adding a date to the release log line, if not present)
• Maintainer bumps versions in the same way as they are done today
• Maintainer opens PR with the result from above
• Once merged, packages are released as they are today, using existing GitHub Actions

Next steps

• Investigate tools similar changesets bot to automatically request contributors add a changeset

[CarsonRoscoe]

Functionally and README wise, this LGTM, I am happy with this.

My one (minor) concern I want to raise is that towncrier has the user write the changelog info in vim. I think this is fine, if a user is technical enough to be contributing they should know how to i -> [type changes] -> esc:wq. But we need to acknowledge that we are adding a little bit of onboarding friction to contributors.

The base branch was changed.

[cb-heimdall]

✅ Heimdall Review Status

Requirement	Status	More Info
Reviews	✅ 1/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[0xRAG]

Functionally and README wise, this LGTM, I am happy with this.

My one (minor) concern I want to raise is that towncrier has the user write the changelog info in vim. I think this is fine, if a user is technical enough to be contributing they should know how to i -> [type changes] -> esc:wq. But we need to acknowledge that we are adding a little bit of onboarding friction to contributors.

That's a good point, and depends on how the user initiates towncrier. If they follow the guide in the contributing, they won't have to enter vim, as they will specify the changelog in a command line argument. Will keep an eye on this

[CarsonRoscoe]

LGTM

[0xRAG]

What changed?

This PR introduces towncrier to manage the AgentKit.py changelogs. While towncrier can support a monorepo setup, we currently do not treat the Python packages as a monorepo, so I decided to introduce towncrier to each Python package individually.

The following towncrierconfig options are modified:

filename = "CHANGELOG.md"# What we currently usedirectory = "changelog.d/"# Standard used by some open source Python projects
[tool.towncrier.fragment.feature]
name = "Added"# To align with our current changelog format
[tool.towncrier.fragment.bugfix]
name = "Fixed"# To align with our current changelog format

Why?

Contributors can add independent changelog entries without having to worry about or deal with merge conflicts.

Maintainers can generate full changelogs with one command.

The intended contribution workflow is:

• Developer makes a change to some code in a package
• Developer runs poetry run towncrier create from the package folder with appropriate options to write a changelog entry
• Developer checks in generated entry with their PR
• Maintainer reviews the generated entry for version type and change content. Version type should be feature or bugfix (these are two of towncriers default types, and change content should be in past tense (e.g. "Added new feature", "Fixed the bug")

The release workflow is:

• Maintainer runs poetry run towncrier which will consume changelog entries in .changelog.d/ and append to the CHANGELOG.md
• Maintainer reviews the generated CHANGELOG.md for formatting and makes any changes necessary (for example adding a date to the release log line, if not present)
• Maintainer bumps versions in the same way as they are done today
• Maintainer opens PR with the result from above
• Once merged, packages are released as they are today, using existing GitHub Actions

Next steps

• Investigate tools similar changesets bot to automatically request contributors add a changeset

[CarsonRoscoe]

Functionally and README wise, this LGTM, I am happy with this.

My one (minor) concern I want to raise is that towncrier has the user write the changelog info in vim. I think this is fine, if a user is technical enough to be contributing they should know how to i -> [type changes] -> esc:wq. But we need to acknowledge that we are adding a little bit of onboarding friction to contributors.

The base branch was changed.

[cb-heimdall]

✅ Heimdall Review Status

Requirement	Status	More Info
Reviews	✅ 1/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[0xRAG]

Functionally and README wise, this LGTM, I am happy with this.

My one (minor) concern I want to raise is that towncrier has the user write the changelog info in vim. I think this is fine, if a user is technical enough to be contributing they should know how to i -> [type changes] -> esc:wq. But we need to acknowledge that we are adding a little bit of onboarding friction to contributors.

That's a good point, and depends on how the user initiates towncrier. If they follow the guide in the contributing, they won't have to enter vim, as they will specify the changelog in a command line argument. Will keep an eye on this

[CarsonRoscoe]

LGTM

[0xRAG]

What changed?

This PR introduces towncrier to manage the AgentKit.py changelogs. While towncrier can support a monorepo setup, we currently do not treat the Python packages as a monorepo, so I decided to introduce towncrier to each Python package individually.

The following towncrierconfig options are modified:

filename = "CHANGELOG.md"# What we currently usedirectory = "changelog.d/"# Standard used by some open source Python projects
[tool.towncrier.fragment.feature]
name = "Added"# To align with our current changelog format
[tool.towncrier.fragment.bugfix]
name = "Fixed"# To align with our current changelog format

Why?

Contributors can add independent changelog entries without having to worry about or deal with merge conflicts.

Maintainers can generate full changelogs with one command.

The intended contribution workflow is:

• Developer makes a change to some code in a package
• Developer runs poetry run towncrier create from the package folder with appropriate options to write a changelog entry
• Developer checks in generated entry with their PR
• Maintainer reviews the generated entry for version type and change content. Version type should be feature or bugfix (these are two of towncriers default types, and change content should be in past tense (e.g. "Added new feature", "Fixed the bug")

The release workflow is:

• Maintainer runs poetry run towncrier which will consume changelog entries in .changelog.d/ and append to the CHANGELOG.md
• Maintainer reviews the generated CHANGELOG.md for formatting and makes any changes necessary (for example adding a date to the release log line, if not present)
• Maintainer bumps versions in the same way as they are done today
• Maintainer opens PR with the result from above
• Once merged, packages are released as they are today, using existing GitHub Actions

Next steps

• Investigate tools similar changesets bot to automatically request contributors add a changeset

[CarsonRoscoe]

Functionally and README wise, this LGTM, I am happy with this.

My one (minor) concern I want to raise is that towncrier has the user write the changelog info in vim. I think this is fine, if a user is technical enough to be contributing they should know how to i -> [type changes] -> esc:wq. But we need to acknowledge that we are adding a little bit of onboarding friction to contributors.

The base branch was changed.

[cb-heimdall]

✅ Heimdall Review Status

Requirement	Status	More Info
Reviews	✅ 1/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[0xRAG]

Functionally and README wise, this LGTM, I am happy with this.

My one (minor) concern I want to raise is that towncrier has the user write the changelog info in vim. I think this is fine, if a user is technical enough to be contributing they should know how to i -> [type changes] -> esc:wq. But we need to acknowledge that we are adding a little bit of onboarding friction to contributors.

That's a good point, and depends on how the user initiates towncrier. If they follow the guide in the contributing, they won't have to enter vim, as they will specify the changelog in a command line argument. Will keep an eye on this

[CarsonRoscoe]

LGTM