> You can do that within a major version, except for one case - multiple > developers creating diverged versions of 2.13, based on 2.12, each with > their own features. > ... > But doing it per major version recursively raises the question of which > major version is authorised: what if you have a single library at 19.x, > and TWO people create 20.0 independently? Again, you have > incompatibility. So, you're back to the question of (a): is it the same > library, or should an author simply stay within the bounds of a > library's API, and fork a new CONCEPTUALLY DIFFERENT new lib (most > likely with a new name) when they break that API?
I think that forks should be considered as completely different libraries. This shouldn't be a problem when certain naming scheme is used, for example, two-level names like in Java world. Central repository will certainly help, because each entry in it will be controlled by concrete user. These entries can also be linked with version control stream which represents main development line. No ambiguities here. It may be desirable then to use specific fork instead of the mainline project. This can be a feature of overriding system, which will be present anyway. If the user wants to use a fork instead of a library (all its versions or a specific version), he/she will be able to specify this requirement somehow, and dependency resolver will take it into account. Obviously, package authors will be able to choose default "fork" which they want to use. > But what does the user know about library APIs? He needs to dig into > the logic of the program, and worse, the logic of underlying libraries, > to figure out that: > > somelib::begin() from > github://somelib/someplace/v23.2/src/module1/submod2/utils.rs, line 24 > > does not mean the same as: > > somelib::begin() from > github://somelib/otherplace/v23.2/src/module1/submod2/utils.rs, line 35 > > ! ;) > When this API is used directly by the package, then the user *should* know about it. He's using it, after all. If this API belongs to a transitive dependency, then I don't think there is an ideal solution. Either the version is pinned (like in Java world), or it is chosen by the dependency resolver. In the former case all transitive dependencies are guaranteed to be intercompatible, because these pinned versions were deliberately chosen by libraries developers. In the latter case there is always a possibility of compatibility problems, because it is impossible to guarantee complete compatibility - libraries are written by people, after all. Then it is the user's responsibility to resolve these problems, no one else will be able to do this. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
