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

Create a new and recent github release that reflects the current state of the repo #1902

Open
Jturnerusa opened this issue Sep 12, 2021 · 2 comments

Comments

@Jturnerusa
Copy link

The most recent GitHub release available is from 2017 which is now several years old.

Most people probably clone the repo directly or install from melpa, and for those users this probably doesn't matter. However, some Linux distros will package popular emacs packages and put them directly into the distros repo(s), which allows installing and managing emacs packages through the system package manager.

On Gentoo it's preferred to be able to use an official release for the source of the build, and pulling directly from VCS is restricted to "live" builds and are mostly for development purposes from my understanding. Using a random snapshot is allowed and is an option but an actual release is probably the better solution.

Hopefully this isn't too big of an issue, and sorry if I am incorrectly creating an issue somehow, I don't use GitHub super often. Thanks :)

Disclaimer: I am not a gentoo developer, or speaking on behalf of them, but I plan on contributing the ebuilds to the Gentoo repos if possible.

@mavit
Copy link
Contributor

mavit commented Sep 12, 2021

This is a duplicate of #1754.

@Jturnerusa
Copy link
Author

Jturnerusa commented Sep 12, 2021

I do not necessarily need or want it to be bumped to version 32, though if that is the most recent version then it makes sense I guess.

Ideally there could be semi-frequent github releases a few times a years, or whatever frequency makes the most sense, but not just for every major version bump every few years. So instead of only releasing 30 -> 31 -> 32, there would be 31-2021.04.11 -> 31-2021.09.11 or something similar to that.

I'm not sure how melpa works in this case, whether it just pulls from VCS every so often or if the owner has to publish the new work, but the idea is to have roughly as modern of versions of flycheck available from the releases as from melpa.

From what I can tell the other potential duplicate issue is about just releasing 32, which would work only for a short time for this use case but then run into the same problem as now when it eventually becomes out of date.

Also if it's just the case that flycheck actually does move as slowly as the releases make it seem then I guess this can all be ignored, but I don't think that's the case right?

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

No branches or pull requests

2 participants