Ideas/proposal for AutoPub 1.0

[patrick91]

Hi everyone, I wanted to write this a long time ago. I've been using autopub for a while on Strawberry's repo and I think it is time to think about AutoPub 1.0.

I'm going to list some of the use cases we have in Strawberry, and then some use cases we might want to make autopub more flexible.

• update the GitHub release with the information of PR author and with a link to the PR
  • Personally I'd also list reviewers and commiters, we do get PRs that have commits from multiple people sometimes
• send a tweet after the PR has been released, to thank the authors
  • again, we should do this for reviewers and committers too
• pre-release
  • we currently have a manual command that creates a pre-release, this was done by @marcoacierno (thanks again) and it has been very helpful. I think we could have a autopub pre-release

and some other use cases I think we should support

• other package managers other than poetry
  • there's tools like hatch, pdm and probably more
• allow publishing on private repositories
• add support for CalVer (we know people that prefer CalVer to semver[1])
  • this might also mean we do some tweaks to the release file

I don't have a lot of ideas on how we build this, yet. I thought having a autopub-core that knows the basics (reading the release file, getting info about a PR, etc) and a few autopub-integration (eg autopub-poetry) that know how to use the individual package managers to build and publish. And for things that aren't related to autopub we can use plugins.

[1] maybe we should use frontmatter for defining metadata inside the release file :)

[justinmayer]

Many thanks for taking the time to write down these ideas, Patrick. I agree that AutoPub could be more modular, which would allow it to address more use cases while still keeping core functionality as straightforward as possible.

I really like the idea of adding automation to post to Twitter to thank those who made the release possible. I’d love to extend that even further by automatically generating release announcement blog posts. I can certainly see the value in many of the other use cases as well.

As you said, I have few ideas regarding how to implement this modularity, but I’m certainly open to suggestions. I think the general approach you proposed seems sensible enough to me.

With that all said, how do you think we should get this endeavor started?

(I changed the title from autopub 2 👉 AutoPub 1.0 since we’re still on 0.x… Looking forward to 1.0!)

[patrick91]

Many thanks for taking the time to write down these ideas, Patrick. I agree that AutoPub could be more modular, which would allow it to address more use cases while still keeping core functionality as straightforward as possible.

I really like the idea of adding automation to post to Twitter to thank those who made the release possible. I’d love to extend that even further by automatically generating release announcement blog posts. I can certainly see the value in many of the other use cases as well.

Oh I love this idea!

As you said, I have few ideas regarding how to implement this modularity, but I’m certainly open to suggestions. I think the general approach you proposed seems sensible enough to me.

With that all said, how do you think we should get this endeavor started?

Good question! Maybe we can spend an hour together sketching out the design proposal and then we can implement it[1]. We could do this at EuroPython 😊 Unfortunately I won't be around for the sprints, but I think we could find 1 hour to talk during the week :)

(I changed the title from autopub 2 👉 AutoPub 1.0 since we’re still on 0.x… Looking forward to 1.0!)

👍

[1] I think I can ask a friend to help (or to pair program with me), if you're busy with other things :)

[justinmayer]

Great! I'll reach out to coordinate a time for us to meet this week at EuroPython.

[nrbnlulu]

I would add that currently a PR=Release which is not very usual thing especially for projects with lot's of PR's. A release then basically means nothing for a user. I would think of something like this.

1. A contributor creates a PR with NORELEASE.md with change type: FEATURE | CHORE | REFACTOR | INTERNAL
2. autopub appends this to a json file that saves the last PR's details and deletes this file when PR is merged.
3. A maintainer that wants to publish a release creates a PR with RELEASE.md just like now and adds some notes by hand the rest of the notes would be appended by autopub from the json file and this file gets cleared.

[justinmayer]

The vast majority of projects do not receive high PR volume, and thus high-PR-volume projects are a distinct minority. I do not want to optimize for the minority case.

PR = release is actually the goal. That goal isn't achieved in every situation, because every situation is different. Sometimes multiple PRs are combined into a release, and that's okay. The act of issuing a release remains ultimately a manual process performed by maintainers who have the power to modify PRs and add/delete/adjust RELEASE.md files. But when the system works as designed, maintainers can just tap the Merge button to issue a release with no further work required.

I am open to alternative release flows that would collect change-log entries from PRs and then assemble them into a combined release. Such an endeavor is probably best suited as a plugin, and thanks to @patrick91, a modular design that supports plugins is already in the works.