Search Criteria
Package Details: mpz 1.1.0-2
Package Actions
Git Clone URL: | https://aur.archlinux.org/mpz.git (read-only, click to copy) |
---|---|
Package Base: | mpz |
Description: | Music player for the large local collections |
Upstream URL: | https://github.com/olegantonyan/mpz |
Keywords: | audio multimedia music music-player |
Licenses: | GPL3 |
Provides: | mpz |
Submitter: | oleg_antonyan |
Maintainer: | oleg_antonyan |
Last Packager: | oleg_antonyan |
Votes: | 3 |
Popularity: | 0.000000 |
First Submitted: | 2020-09-25 05:40 (UTC) |
Last Updated: | 2024-12-18 08:05 (UTC) |
Latest Comments
oleg_antonyan commented on 2020-10-06 06:11 (UTC)
Release trigger changed from each commit to github release. Should be no more than 1 new version a day. No intentions to maintain another "-git" package so far, b/c I want to keep release procedure as similar as possible across all supported distros, and also avoid multiple PKGBUILDs.
haawda commented on 2020-10-05 08:01 (UTC)
Thanks for explaining. I have no strong opinion for keeping it the way it is, let's see what others think.
oleg_antonyan commented on 2020-10-05 05:14 (UTC) (edited on 2020-10-05 05:36 (UTC) by oleg_antonyan)
Ok, didn't know about daemon and annoying notifications.
Here's more context on "why". This project was born to serve my own needs. But there could be someone in the world with similar needs. Thus, it must be opensource. But you can't expect "build and they will come" - you need to package it as a product, or at least into something that resembles a product. This includes promotion, good readme, ease of installation, intuitive UI, being heard by developer when needed. Most likely nobody needs this project and I'm the only one with such weird ideas of a music player. But how would you know that without a try?
Right now it is in pre-release state, meaning it's almost done but was not promoted yet. It does not resemble a product yet. Once everything is done there will be a site, better readme, few posts on relevant social media and version number 1.0.0. As mentioned above one of the most important things is ease of installation. Thus, before "initial public release" I must make it easy to install, otherwise a good chunk of people just won't even try to clone repo and build from sources. I managed to achieve this with Open Build Service https://build.opensuse.org/package/show/home:oleg_antonyan/mpz. Each commit triggers rebuild for 6 distros and 4 architectures and pushes artifacts into repositories. OBS also supports Arch, but I couldn't make it work and on top of that for Arch users there's AUR - it should be more familiar and trustworthy. I wanted to keep the process on my end the same - just git push and get all the packages for all supported distro. Thus, this script for Github actions was born https://github.com/olegantonyan/mpz/blob/master/.github/release-aur-github-action.rb - it gets triggered on each commit and push everything to AUR. Perfect, I thought. "Ease of installation" step is done.
I thought that most users don't care if there are 15 new versions each day - they just don't check it all the time. It's much easier for me to just git push and get all the packages ready for all supported distros. And at this stage I can guarantee that each commit is stable enough to be considered as a stable version. If this project will get some traction, if there will be a lot of feature requests and maybe even another interested developer, then this whole release process should be reconsidered. Maybe I'm wrong, maybe it should be different from the day one. One possibility would be to trigger rebuilds only on creating Github releases. Right now I use Github releases only for windows binaries b/c they have to be built locally, no free CI here. Will think about triggering build on github releases.
Hope all this makes sense.
haawda commented on 2020-10-04 22:09 (UTC)
I added you as co-maintainer to the existing package mpz-git.
Well, I used to have mpz installed, and it is just inconvenient for users who, like me, have an daemon installed that notifies sometimes within minutes that a new version is out. It is inconvenient to fetch the PKGBUILD, check if there are more changes than a version bump + shasum change and than run makepkg on it. just running makepkg on a -git-package is much more convenient.
In terms of guidelines you may be allowed to do what you do, but I disagree to your consideration of stableness. How can a version be stable if it changes 15 times in one day (this is what happened 4 days ago)?
But maybe this should be discussed on aur-general mailing list.
oleg_antonyan commented on 2020-10-04 17:09 (UTC) (edited on 2020-10-04 18:30 (UTC) by oleg_antonyan)
Should I rename it to mpz-git? B/c it's kind of the whole point of CI. Besides, I consider every commit a stable release. Thus the pgrel - a number of commits since the last tag - a "stable" release on github. I couldn't find any rule (https://wiki.archlinux.org/index.php/AUR_submission_guidelines) that prohibits such scenarios, only circumstantial suggestions on reddit to use '-git' for bleeding edge packages. But again, I consider every commit stable at this moment. This package is not in community repo. But I'm willing to follow the rules if there are such rules
haawda commented on 2020-10-04 16:15 (UTC)
Please stop trying to upload every single commit to AUR. That is what -git packages are meant for.
haawda commented on 2020-09-29 11:07 (UTC) (edited on 2020-09-29 11:08 (UTC) by haawda)
Please rename the downloaded tarball to mpz-$pkgver.zip or so.