#microformats 2025-12-15

2025-12-15 UTC
gRegor-web, gRegor, Saige_Leah and [pfefferle] joined the channel
#
[pfefferle] [gRegorLove] when we want to follow the semantic versioning, we should have a 1.0.0 when raising the php requirement, because it is a breaking change
#
jkingweb There are two schools of thought on this. The semver FAQs themselves, though, suggest that updating a dependency is not a breaking change, as long as the API remains compatible. So, if you use new PHP functions, not a breaking change. If you change function signatures to add newly expressible type information, though, that would be.
sarat joined the channel
#
[pfefferle] that is true... simply raising the required version without updating the code would be no major change, but I would assume that we would remove some backwards compats in this case...
#
jkingweb Presumably.
[lazcorp] and Dryusdan joined the channel
#
[tantek] the h-card spec is definitive. what does more "definitive" mean to you?
[snarfed] and gRegor joined the channel
#
gRegor Perhaps, but we're still on major version 0. "Anything MAY change at any time. The public API SHOULD NOT be considered stable." I think there's a github issue discussing some things we'd like before we make a proper 1.0.0, even if, in practice, it is quite stable in recent releases.
#
gRegor I don't have a strong opinion on it. We could probably make the next one 1.0.0
#
gRegor https://github.com/microformats/php-mf2/issues/232
Dryusdan joined the channel
#
[social] Do you have criteria for demarcating v 1.0.0?
#
[snarfed] on one hand, I like the convention that even if you do semver, 0.x releases are special in a sense, they're *all* unstable, you haven't committed to compatibility guarantees, breaking vs non-breaking changes yet, etc
#
[snarfed] ...on the other hand, php-mf2 has been in production on a wide range of systems and services for, what, 10y ish now? we can say "it's not stable!!!" all we want, but in practice it is, both in that it's not shipping breaking changes all the time (if really at all?), and that it is a load-bearing dependency in the real world, and has been for a long time
#
[artlung] what is semantic versioning?
#
jkingweb See http://semver.org/
#
[artlung] (I forgot that Loqi does not dwell in this channel to respond with https://indieweb.org/Semantic_Versioning )
#
[snarfed] also, unrelated, my experience (in multiple language ecosystems) is that raising the language runtime version req't generally *is* considered a breaking change. maybe PHP is different, but I'd be surprised
#
aaronpk i would definitely consider that a breaking change for php
#
[snarfed] (not that I'm not necessarily advocating for 1.0 or not here. just sayin)
#
aaronpk and yeah i agree the php parser has been pretty stable for a long time. even the breaking changes we've done with it have been strictly following semver too
#
[snarfed] aaronpk wait how? it's not even at 1.x yet
#
aaronpk i mean as if it were 1.x
#
[snarfed] oh, no, I mean, there's never been a major version bump, which implies there's never been a breaking change...?
#
aaronpk oh i guess you're right, we've been using the minor version for that
#
aaronpk 0.5 changed the img parsing for alt text
#
aaronpk 0.4 added rel-urls and dropped some implied p-name parsing
#
[social] Hmm… the semantic versioning wiki may need some attention as it covers changes to major version numbers, but 0.x.x hasn’t hit a major version yet. Having a rough demarcation of what is needed to hit v 1.0.0 would be helpful.
#
gRegor good points, I'm cool with 1.0.0 for next. Would be good to get us onto that for more explicit BC
[Sophia_wood], barnaby, jeremycherfas and AnaOlivia joined the channel