#aaronpkI am worried about people who haven't been active in the community for years, the more accounts with push access the more chance someone's account is compromised and used to push malware to the package
#[jgarber]Looks like [mattl] and I are on Team Ruby along with [aaronpk] . Not sure what permissions that team might have but seems reasonable to tack it on to any Ruby repos on the Organization with “admin” permissions.
#[jgarber](Up to the mods’ discretion there, of course.)
#[mattl]i think that’s a general worry about github orgs and other things.
#[jgarber]Or maybe even “manage” permissions if you want to restrict some of the repository settings access.
#[jgarber]Publishing bad packages is as related but different concern.
#gRegorphp-mf2 got several pull requests, one of which suggests updating minimum PHP to 7.1. I know in the past we've kept to a lower minimum version due to WordPress support, but wondering if we should revisit that now.
#[tantek]philosophically speaking I'd prefer keeping old PHP compat, however I defer to the folks actually maintaining php-mf2 as to the marginal labor for doing so
#aaronpkI don't see any reason to set a new minimum version just for funsies
#aaronpkis there something in particular driving this?
#aaronpkHmm I see... the alternatives to getting support in 8.4 do seem worse
#gRegorI don't have a strong preference, haven't looked at it in depth yet
#jimwit seems very unlikely that someone stuck with php < 7.1 is going to even be upgrading to a new version of php-mf2. composer will just give them last version that included support for whatever very old version of php they're running.
#aaronpkRight, the main concern is whether they want any of the new features in the parser before they are able to upgrade their PHP version
#aaronpkBut IIRC there aren't a lot of new features pending release at the moment so maybe this is a good time to draw that line
to2ds joined the channel
#jimwyeah, looks like it's been a while since a mf2 release, so maybe it makes sense to kick out one last 0.5.x as the last pre-7.1-supporting release and then just immediately release 0.6.0 that adds in the necessary php8.4 changes and drops support for pre-7.1.
#[tantek]There's a bunch of mf2 parsing features in-flight
#[tantek]I would kinda prefer we resolve on those, land spec changes so phpmf2 can roll out prototypes as mainline and then we can consider cutting over
#[tantek]also, I'd like to see someone document the use-case (like in the issue) for this. how will changing min version help users or developers?
#Loqinewminversionforfunsies has -1 karma over the last year
#jimwthe use-case is in the PR, using php-mf2 will emit deprecation warnings in PHP 8.4 (and errors in PHP 9.x) because it uses a syntax that is being obsoleted.
#aaronpkWait what features are in flight? I thought we shipped a bunch recently
#aaronpkIf there are features ready to go then we should knock those out and do a release that's compatible with 7.1 first
#[tantek]aaronpk, spec features in-flight. mf2 parsing issues
#[tantek]upstream from (some) parser implementations
#[tantek]some implementations have already implemented prototypes of proposed resolutions which have not been integrated into the spec yet, per process to try proposals in an implementation or two before resolving/committing to spec
#[tantek]jimw, is there no updated syntax that works (no warnings) in both old and new?
#[tantek]like it's a breaking change in the language?
#[tantek]I'm not clicking on that rn bc I have a feeling it will make me mad
#[tantek]is there not some maxim somewhere like "PHP is not C"?
#jimwnot that i've heard. but certainly the philosophy of the language has changed a lot since the early days. like i said, a bumpy road and some blind alleys. the community does what it can.
#gRegorPersonally I don't think I'll have much time to commit towards getting in-flight parsing issues into php-mf2 in a reasonable timeframe
#gRegorI am interested in which ones you're thinking of, though