Skip to content
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

Please, publish releases, not only tags #116

Open
hurricup opened this issue Feb 26, 2023 · 12 comments
Open

Please, publish releases, not only tags #116

hurricup opened this issue Feb 26, 2023 · 12 comments

Comments

@hurricup
Copy link

It is hard to watch for library changes without it. GH notifies about releases, not tags.

@Leont
Copy link
Member

Leont commented Feb 26, 2023

We publish releases to CPAN

@hurricup
Copy link
Author

Yes I know that.
But it is really comfortable to follow projects releases in one place. and it is not a big deal to draft release. Not necessary to attach archive there, it is more like a flag that specific tag is a release, not just some dev tag.
I'm not even sure if CPAN may notify about new releases.

@demerphq
Copy link
Member

Maybe you should provide a link to docs on this, I have no idea what you are on about. Generally every tag we have in this repo is about a release, it would be unusual/unheard of for a comitter to push a tag for any other reason.

@hurricup
Copy link
Author

@hurricup
Copy link
Author

Looks like this: https://github.com/Camelcade/Perl5-IDEA/releases

@hurricup
Copy link
Author

Or this (this more like perfect releases): https://github.com/shogo82148/actions-setup-perl/releases

@karenetheridge
Copy link
Member

If someone has a Github Action that will create a release when a tag is pushed, I'll apply it to all my repos.

@Leont
Copy link
Member

Leont commented Feb 26, 2023

If someone has a Github Action that will create a release when a tag is pushed, I'll apply it to all my repos.

I think the resulting tarball is only workable if the repository matches the repo 1-on-1. This isn't even the case for this repository at the moment (the META files aren't committed), and it's very much not true for your typical repositories.

@hurricup
Copy link
Author

hurricup commented Feb 26, 2023

I'm not quite sure that someone will really need to have binaries in the release when we have CPAN. This may be useful for artifacts with windows binaries, for example, when we have only not widely used chocolatey. I personally using msys2 binaries this way to configure CI.
For perl distributions it would be nice just to have releases to be able to get notified on updates.

I didn't use this myself, but seems there is an action for this: https://github.com/marketplace/actions/github-create-tag-release

@karenetheridge
Copy link
Member

I suppose if we want the "github release" to match the actual tarball that we uploaded to PAUSE, then we'd need to do this as a post-release action -- such as in a dzil plugin. I'll happily add such a plugin to Dist-Zilla-Plugin-GitHub.

@Leont
Copy link
Member

Leont commented Feb 26, 2023

I suppose if we want the "github release" to match the actual tarball that we uploaded to PAUSE, then we'd need to do this as a post-release action -- such as in a dzil plugin. I'll happily add such a plugin to Dist-Zilla-Plugin-GitHub.

Yeah, I think that'd be a more sensible approach.

@zmughal
Copy link

zmughal commented Feb 27, 2023

For a private non-CPAN dist, I have the following in my dist.ini:

[FakeRelease]

[Run::AfterRelease / GitHubUpload ]
run = gh release create v%v %a

This requires an authenticated gh CLI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants