Automatic release about prose HOT 4 CLOSED

@lgrcia Exactly. I think we should follow the process of, on creating a merge request, we run the test and lint suite.

Applying a blocker on the tests passing before it can be merged. At first, the tests may seem trivial but when they fail ... it's really insightful to see how a small change actually can brake things in unexpected ways.

And then on tag and release, we could run the full lint, test, coverage, build and submit to pypi for release.

I think that way, everything should be covered. I'll look to set this up for twirl ASAP. :)

Certainly let me know if you would like a more formal RFC...

from prose.

@michealroberts, you mentioned this in our discussion, would you be willing to help with that? If you want to check the current status of the project we are actively working on lgrcia/[email protected] that aim to be better documented and with more systematic testings (#56)!

from prose.

@lgrcia Hey Lionel, thanks for the merges this morning :)

Exact. I'd like to add some github actions to this repo that can improve the flow of releases as well as provide automated release notes / change logs.

I propose the following automated release process:

• When we're ready to release, we tag the master / main branch with a version, e.g., v3.0.0, or 3.0.0 (which ever style you prefer).
• We then push that release tag to the master branch.
• We then publish a new release via Github, which looks up this newly created tag using semantic versioning
• This on publish hook can trigger the build process for publishing to pypi ...

So we have the publishing automated on the release hook being triggered. This is how I usually do this in most of my typescript projects which works really well, it's semi-automated in the sense that we are in control of when to tag and when to the release, e.g., we can revert a tagging if we're not happy etc.

from prose.

That seems great! I am happy to review a PR for that (I'll read some documentation to be able to contribute as well). I like the release pipeline of projects like exoplanet-dev/exoplanet. This is close to the structure you mention, right?

from prose.