Hello! I co-maintain the Debian packaging of pydantic and pydantic-core, and I'm trying to decide on the best way to do things now that pydantic-core has been merged into the pydantic git repository.

As background for my question, Debian packages are structured as "source packages" which build one or more "binary packages" (debs). Source packages usually correspond to an upstream project in some sense: for example, the glibc source package builds libc6, libc-bin, locales, and so on. In the case of Python modules packaged in Debian, each source package is usually based either on tags from an upstream git repository, or on sdists published to PyPI; there are a number of cases where only one or the other approach will do. The only way for code changes to get into the distribution is by uploading new versions of source packages, which are then autobuilt on each relevant architecture to produce binary packages. Normally, binary packages have the same version as their "parent" source package, but it's possible to override this.

Before pydantic-core was merged into the pydantic repository, our approach was obvious. pydantic and pydantic-core were separate git repositories and separate projects on PyPI, so clearly they had to be separate source packages too. (As it happens, we got the source code from git tags, but it probably could have worked either way.)

In the case of pydantic >= 3.13 and pydantic-core >= 2.46, I could see this working one of two different ways:

1. Keep them as two separate source packages. Since there are no git tags corresponding to new pydantic-core versions any more, this would probably mean getting the source to pydantic-core from PyPI, and we might then exclude the pydantic-core/ subdirectory from our pydantic source package to avoid people being confused into thinking that it was used for anything.
2. Merge them into a single source package, building both python3-pydantic-core and python3-pydantic binary packages which would correspond to the pydantic_core and pydantic Python package names. We'd generate python3-pydantic-core's version based on the version field in pydantic-core/Cargo.toml.

Option 2 is appealing: although the packaging code would be a bit more complex, it would simplify updates in some ways because we wouldn't need to worry about making sure that pydantic-core and pydantic are upgraded in sync. However, it only really works if pydantic and pydantic-core releases are going to happen in lockstep from here on. I can see on the v2.13-fixes branch that each 2.13.* release of pydantic has had a corresponding 2.46.* release of pydantic-core. Could the maintainers please confirm: is that sort of thing how all future releases of both packages are going to work, or is there a possibility that there will be some releases of one package without the other?

If releases aren't going to be in lockstep, could we have a renewed practice of tagging each pydantic-core release (presumably with a pydantic-core- prefix on the tag, or something like that), so that we can tell them apart properly in git?

Thank you!