@ricardoboss the CI is failing, would you mind having a look when you have a minute please?

@baywet the CI failing is expected since the packages now depend on the version that is available on pub.dev. Since we haven't published any packages yet, the CI cannot get them.

This should be resolved once we publish the first version.

Thank you for the additional information.

Is there no way to setup a fallback? I'm worried about a few things:

• depending on how much time we take for the initial publish, it might mask broken additional changes.
• contributors will have to change those back when working on changes across multiple projects.
• publishing might initially fail because of the lack of a specific version, also the workflow will have to publish in the order of the dependency tree.

AFAIK there is no kind of fallback behaviour for pub dependencies. I have an idea how to work around this though:

1. replace all dependencies with git dependencies (i.e. cherry pick this commit: c1465a6)
2. replace all those dependencies with a specific version when publishing

This would allow us to ensure compatibility with the main branch while developing PRs but also requires more attention when publishing versions (pub.dev doesn't allow path or git dependencies in published packages).

We could also temporarily use dependency_overrides to change the dependencies to path/git until the first version is published https://dart.dev/tools/pub/dependencies#dependency-overrides

Thank you for the additional information.

After thinking about this more, I believe we should leave the versions in. One of the rationales being: release please won't be able to orchestrate versions if we leave local or git references in the code.

As for dependencies override, I think it'd be a great thing to document in a development.md