RFC: Export versioning

[Keno]

RFC: Export versioning

[bvdmitri]

As a package developer I would comment that this seems a bit too intimidating and my mental model just does not work on the provided code snippets. Not talking for everyone, but it just does not feel intuitive and instead brings some complex mental exercise. It's quite difficult to keep in mind potentially different API of one dependency.

Currently, because the view of exported symbols is
consistent for all packages, I would need to update my other dependency to the new
Graphs version before I could use the unrelated new feature.

Why is it a big problem? It is annoying for sure, but this proposal suggests to create a universe of madness in the API's of dependencies. Just fixing your package to a new version of some dependency seems mentally easier than tracking potentially different versions of API of the same dependency. I'm not even saying that proper IDE integration of this proposal might be quite difficult as well.

[kimikage]

I am not sure if this is a good proposal since I do not fully understand the following two points:

• What is the "version" or "version range" here?
  • julia, package, or API (more loosely coupled with the implementation)?
• When is the version determined and when are the version ranges evaluated?
  • Depending on the timing of the evaluation, it does not seem to be very compatible with existing isdefined switches, precompilation caches, etc.

My underlying concern is that this may not be very compatible with the SemVer management of packages and stdlibs.

Edit: This seems to be a problem of my poor comprehension skills.

[Seelengrab]

One additional worry I have with this is that this yet again doesn't handle "small" API changes relating to a single signature/method. For an already exported name, it's impossible to communicate that a new signature is now supported API from a given version onwards. Is the intended solution to use a new name so that it can be versioned? That seems backwards to me.