On Thu, 21 Nov 2019 at 17:15, Andreas Tille <[email protected]> wrote: > On Thu, Nov 21, 2019 at 03:26:40PM +0000, Carnė Draug wrote: > > I also changed some others things that you may have different opinion > > of. > > I'm wondering about pointing the watch file to CPAN. While I definitely > agree that versioned releases would be great and should show up on CPAN > upstream does not seem to do this. Github is way more recent which I > noticed when I imported the version from CPAN (to match your watch file > suggestion). This leaded to the same failure as before and I needed to > provide the latest Build.PL from Github as quilt patch to be able to > build the package. > > This makes me wonder in how far it is a good idea to rely on CPAN if > upstream is just not caring about proper releases. Any opinions?
Upstream seems to be making CPAN releases, at least the latest version number is the same in both metacpan and github. If I understood you correctly, the issue is that upstream botches their CPAN releases. Here's some reasons why I would still favour the stuff on CPAN: 1. Github provides snaphots of the repository. While a snapshot of the repository can be equal to a release they are not the release itself (even if github calls them releases). Depending on the release process, some files may be created or removed to create the actual release file. For example, the Makefile.PL and Build.PL files are sometimes created during the release and will not appear in the repo snapshot. 2. Other users installing packages with perl tools to manage modules will be installing from CPAN not from github. If someone told me they used version X and I had to replicate it, I would guess they meant the version from CPAN not the one tagged as such on the upstream repository. 3. Upstream can change the location of, or even remove, its repository. Upstream can also force push changes to the repo and modify tags. If I had to choose, I would bet on CPAN releases being more persistent. 4. I know upstream sometimes botch their releases. But it goes both ways. I am also familiar with cases where upstream forgets to add files under version control. Those extra files appear on the released package but not the repository. If problems can be in both places, then I think it's the release that counts. It's on the name.
