nightlark wrote:

> This is a good question I don't know answer to. Debian packages from our APT 
> repository seems to specify `LLVM Packaging Team 
> <[email protected]>` as the maintainer and their email.

Are there any other support-ish email addresses used by LLVM? I guess if 
there's official LLVM bindings for another package manager, it would be 
interesting to see if they also list the Debian packaging email (we might not 
want someone focused on debian specifically to start getting contacted about 
the Python bindings).

> Sorry for not articulating my concerns clearly enough. I'm not too concerned 
> with bugs, as bugs will be eventually found and fixed, but I'm concerned with 
> bugs that we'll have hard time fixing due to backwards compatibility 
> concerns. One such thing I can imagine is users depending on a particular 
> version string format, then we realize it doesn't match what the rest of LLVM 
> does, and have hard time fixing that.

[Version 
specifiers](https://packaging.python.org/en/latest/specifications/version-specifiers/#version-specifiers)
 defines what is a valid version number for Python packages, so we're working 
within the constraints of what is allowed in Python packages. They must fit the 
scheme `[N!]N(.N)*[{a|b|rc}N][.postN][.devN]`:
* `[N!]` is the epoch, which is irrelevant since LLVM doesn't use it (and tbh, 
I can't think of any other Python packages I've seen use it either)
* `N(.N)*` is the release segment, which is a straightforward mapping to the 
version number in `llvmorg-x.y.z` and `llvmorg-x.y.z-rcN` tags, and a bit weird 
but at least gets the major version number from `llvmorg-x-init` tags (but this 
last one is irrelevant for building wheels that end up on PyPI, which is what 
users will ultimately use; y.z are implicitly considered 0's if a python 
package only lists the major version number)
* `{a|b|rc}N` is the pre-release segment, which will get picked up when 
building this package for the `llvmorg-x.y.z-rcN` tags; the `a` and `b` 
pre-release markers will never appear
* `.postN` is a post-release marker, which could be used for minor errors like 
fixing metadata in the package before a later llvm release; or we can just 
never use it and wait for another llvm patch release to publish an updated 
version (so end users will never see it)
* `.devN` is a development version marker, which again for LLVM we can just 
ignore and never publish to PyPI so end users will never see it

https://github.com/llvm/llvm-project/pull/125806
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to