Update composer dependencies version requirements

[luanperosa]

If we run composer require marko/blog I get this

Problem 1
    - Root composer.json requires marko/blog * -> satisfiable by marko/blog[0.0.1, 0.0.2, 0.1.0].
    - marko/blog 0.0.1 requires marko/core 0.0.1 -> found marko/core[0.0.1] but it conflicts with your root composer.json require (^0.1.0).
    - marko/blog 0.0.2 requires marko/core 0.0.2 -> found marko/core[0.0.2] but it conflicts with your root composer.json require (^0.1.0).
    - marko/blog 0.1.0 requires marko/database 0.1.0 -> found marko/database[dev-main, dev-develop, 0.0.1, 0.0.2] but it does not match the constraint.

and even if we try to composer require marko/database I also get the same issue.

Problem 1
    - Root composer.json requires marko/database * -> satisfiable by marko/database[0.0.1, 0.0.2].
    - marko/database 0.0.1 requires marko/core 0.0.1 -> found marko/core[0.0.1] but it conflicts with your root composer.json require (^0.1.0).
    - marko/database 0.0.2 requires marko/core 0.0.2 -> found marko/core[0.0.2] but it conflicts with your root composer.json require (^0.1.0).

So we need to update the composer.json verions of these modules

[teunissenstefan]

This seems to be the case because its submodules are required to be the same version ("self.version") as the main module, which isn't going to work when one of the required modules doesn't have exactly the same version number available.

A temporary workaround, until this is fixed, is to downgrade marko/framework: composer require marko/framework:0.0.1 -W. This allowed me to install marko/blog, to play around with Marko.

[markshust]

It actually looks like marko/database never got the 0.1.0 tag: https://packagist.org/packages/marko/database

I'll find out why, but will try to tag this right now to get this resolved.

FYI all packages will have all the same release numbers on each new tag; that's how things are architected (at the moment). This avoids confusion between modules and keeps everything aligned. Open to suggestions for alternatives.

[markshust]

Ok, marko/database should now have a 0.1.0 tag. A simple "update" over on Packagist resolved this; it feels like perhaps the Packagist API hiccuped during the last release, but I'll double-check.

[luanperosa]

Great it worked now. Thank you @markshust

[markshust]

Odd... as the last deployment says it tagged it as 0.1.0 https://github.com/marko-php/marko/actions/runs/23749098046/job/69185794538

[markshust]

Working on a fix:

Root Cause                                                                                                                                               
                                                                                                                                                           
The marko-database Packagist webhook delivery failed with a 502 (Bad Gateway) from Packagist at 2026-03-30T14:09:48Z. Compare:                           
                                                                                                                                                           
  ┌────────────────┬───────────────┬───────────────┐                                                                                                       
  │      Repo      │ Delivery Time │    Status     │
  ├────────────────┼───────────────┼───────────────┤                                                                                                       
  │ marko-core     │ 14:09:00      │ 202 (success) │
  ├────────────────┼───────────────┼───────────────┤
  │ marko-blog     │ 14:09:04      │ 202 (success) │                                                                                                       
  ├────────────────┼───────────────┼───────────────┤
  │ marko-database │ 14:09:48      │ 502 (failed)  │                                                                                                       
  └────────────────┴───────────────┴───────────────┘                                                                                                       
                                               
The split action pushed the tag correctly to marko-php/marko-database (the tag was there all along), but when GitHub fired the webhook to notify         
Packagist, Packagist returned a 502 error. Since GitHub doesn't auto-retry failed webhook deliveries by default, Packagist never learned about the 0.1.0
tag — until you manually clicked "Update".                                                                                                               
                                     
How to Prevent This                          

The split workflow should proactively notify Packagist via its API after each push, rather than relying solely on webhooks. This way, even if the webhook
delivery fails, Packagist still gets updated.