[rust-dev] Deprecating rustpkg

Gaetan gaetan at xeberon.net
Fri Jan 31 02:16:06 PST 2014


>
> 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
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140131/8c5533f2/attachment.html>


More information about the Rust-dev mailing list