Open patrick91 opened 2 years ago
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!)
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 :)
Great! I'll reach out to coordinate a time for us to meet this week at EuroPython.
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.
NORELEASE.md
with change type: FEATURE | CHORE | REFACTOR | INTERNAL
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. 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.
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.
autopub pre-release
and some other use cases I think we should support
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 fewautopub-integration
(egautopub-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 :)