> > 1) If a minor change or bugfix happens, increment the minor version. > 2) If a major change, which is backwards compatible (i.e., new features) > happens, then increment the major version. > 3) When loading libraries, you can specify a major and a minor version, > with 0 for the minor version if you like. You get at least that version, > or better, or the loading fails. > 4) If an incompatible change happens, then it's not fulfilling the same > library API any more, so you stop trying to force square pegs into round > holes, and **just rename the damn thing** ;) ;) > > Rule 4 seems to be where every other OS's libraries makes a big mistake. >
It's a matter of politics. You can't choose for every project. Just let people choose what is best for them. Versionning system for each project is different, versionning on windows libraries is different than on linux or mac. For the internet age, there are new complexities of decentralised forks, I > think we'd need a few more rules: > > 5) Library names have namespaces, something like Java's (and go's?) > com.org.libname system > I hate this. Even if this is very logicial, it's anti ergonomic. What more ugly than having the first directory in you source base named "com" or "org"...... > 6) Anything unofficial (i.e., your patch to version 1.3, bringing it to an > UNOFFICIAL version 1.4) goes in your own namespace, until accepted into the > official codebase, OR you fork your own, NEW, incompatible library, as in > (4)+(5). > > > -- > Lee > > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
