invidious
invidious copied to clipboard
[Feature request] Monthly release
Is your feature request related to a problem? Please describe. The newest release of invidious is over a year old and master evolved a lot since. For new users or people willing to follow Invidious' evolution without checking the commit history, having no release for such a long period of time is very confusing.
There is also no "reference" version to pull and install and people rely on the master branch that might have bugs introduced by a recent commit or pre-requites that are not clearly stated (for example, master requires Crystal 0.36 but I did not see any mention of it)
Describe the solution you'd like A more regular release cycle would help people to keep track of the changes and upgrade their instance on a regular basis. I'd suggest a monthly release cycle, with release named as YEAR.MONTH.BUGFIX.
The release would contain a generated change log with the list of PRs and issues fixed during the past month.
A week prior to the release, only fixes would be accepted in master to avoid introducing last-minute changes that might create issues and let instances based on master report issues and bug that would be high priority.
Version could also be a requirement to create new issues so the contributors can keep a better track of the issues and whether they were fixed or not since the release.
Currently this requires far too much management, and sadly, I (and I'm guessing @Perflyst ) don't have enough time for that.
I'm not against it, but we need (partial, or better, complete) automation for this.
Maybe in the future, or if someone know a Github actions that is smart enough, and is ready to open a PR for that... sure!
I've automated the creating of a branch, named YYYY.MM.01, on the 25th (was supposed to be 23, no idea why I used 25) then on the first of each month a tag and release is made.
My thought right now was to delete branches that are two months old, but if someone thinks this is wrong, do tell me. Or any other thoughs for that matter.
The strategy seems good. If the tag references a commit that exists on master, it will be kept anyway, and release will have a copy of the source code, so nothing is lost even tho the branch has been deleted.
This issue has been automatically marked as stale and will be closed in 30 days because it has not had recent activity and is much likely outdated. If you think this issue is still relevant and applicable, you just have to post a comment and it will be unmarked.