Hi Neil, Thanks for looking into this.
What actually happened was the other way around - I tried releasing v33.0.0 first and got a "status : Not indexed because permission missing." email report, so then Laura re-released it and it went through correctly. Could it be that the co-maint setting takes a bit to propagate, and when I published the first time it wasn't settled yet? (Just guessing) On Tue, Aug 11, 2026 at 11:16 AM Neil Bowers <[email protected]> wrote: > Hi Laura & Mattia, > > We're talking about the Google-Ads-GoogleAds-Client distribution, right? > > I just checked, and MATTIAT has co-maint on all packages in that > distribution. So that's not a problem. > > You didn't say exactly what problem Mattia experienced, but I've found one > problem: > > - In your CPAN directory I can see a release > Google-Ads-GoogleAds-Client-33.0.0.tar.gz > > <https://www.cpan.org/authors/id/C/CH/CHEVALIER/Google-Ads-GoogleAds-Client-33.0.0.tar.gz> > - In Mattia's directory I can see a release > Google-Ads-GoogleAds-Client-33.0.0.tar.gz > > <https://www.cpan.org/authors/id/M/MA/MATTIAT/Google-Ads-GoogleAds-Client-33.0.0.tar.gz> > > You can't release the same version number multiple times - this is a > security restrictions. > > I haven't checked the timestamps on the two releases, but given that yours > is in the CPAN Index, and you're saying that Mattia's failed, then it's a > safe guess that his came second. > > I suspect that Mattia just needs to bump the version before doing a > release, and his release will then be indexed. > > Cheers, > Neil > > On 4 Aug 2026 at 19:36 +0100, Laura Chevalier via modules < > [email protected]>, wrote: > > Hey Neil, > > Thanks for the reply. If I understand what you're saying, the "alternative > interface for adding co-maint per module/package" is what I tried for the > last release. I thought I granted per-module co-maintainership to all > modules in the previous release and the non-version-specific modules, > similar to how you handled it for Dora, but that didn't prevent the > permission problems Mattia ran into. Do you have any idea why that didn't > work this time? > > For your alternative solution, are you suggesting we include only the > latest Google Ads API version in a given dist version, e.g. > Google::Ads::GoogleAds::V25::* in a separate dist version from previous > Google Ads API versions? Or are you proposing putting them under a > separate distribution altogether (e.g., having the package be > Google::Ads::GoogleAds::V25 instead of Google::Ads::GoogleAds)? If I > understand correctly, either option would pose its own problems and > potentially break users' existing integrations or workflows. Let me know if > I've misunderstood. > > If we can resolve the per-module co-maintainership issue, I think that > would be the preferred and sufficiently future-proof solution. If not, we > can look deeper into shared credentials or potentially changing how we > distribute new versions. > > Many thanks, > > > Laura Chevalier > > Developer Relations Engineer > > [email protected] > > > > On Tue, Aug 4, 2026 at 12:02 PM Neil Bowers <[email protected]> wrote: > >> Hi Mattia, >> >> I think what you're saying is that you want multiple people to have >> co-maint on all of the packages in the distribution(s). >> >> But right now you can't use the interface for "give co-maint on the >> distribution", because it times out before it can complete (because of how >> many packages there are in the distribution). >> >> You can use the alternative interface for adding co-maint per >> module/package. I don't think that suffers from the timeout problem, but >> it's a tedious approach for you, given how many packages there are. >> >> Another approach: if I remember rightly, the package explosion is because >> version numbers are embedded in package names, and you want backwards >> compatibility. Could you split off packages to support older versions of >> the API into a separate distribution, or even multiple distributions? >> >> Cheers, >> Neil >> >> >
