-
-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ideas/proposal for AutoPub 1.0 #30
Comments
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!) |
Oh I love this idea!
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 :)
👍 [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.
|
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.
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 :)
The text was updated successfully, but these errors were encountered: