I don't understand this question. The package system doesn't really have a concept of version like you are referring to.<div><br></div><div>The package X is versionless. It is possible to know that your copy of X is different than another's, hence checksums and updating (which should have been called sync, in retrospect.) And you can know that your copy of X isn't the copy that package Y expects, hence the (poorly named) version metadata in the info file. But there is always only one package X i<span></span>n your installation (and no promise that X anywhere else has anything to do with your X.)</div><div><br></div><div>If you want to make a totally new package that has nothing to do with X, as non-backwards compatibility means. Then you are free to name it X and make it difficult for people to maintain old programs using the original X. If you do so, the system will not stop you, but you are going against the advice and experience of the Racket developers wrt quality customer service. </div><div><br></div><div>Jay<br><br>On Sunday, November 30, 2014, Neil Van Dyke <<a href="mailto:neil@neilvandyke.org">neil@neilvandyke.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Any chance of revisiting the new package system's stances on versions -- specifically, on the two issues:<br>
1. Can subsequent versions of a named package (which has an identity)  be non-backward-compatible?<br>
2. Can a Racket setup (and even an individual program) have multiple versions of a package at the same time?<br>
<br>
Regarding #1, the requirement to never make a non-backward-compatible version of a package without giving up package identity is a burden, and a deterrent to third-party package releases.<br>
<br>
For a real-world example, see "<a href="http://planet.racket-lang.org/" target="_blank">http://planet.racket-lang.<u></u>org/</a>", where it looks like most of the familiar names (who were going to a good amount of trouble to release already), managed to release packages marked as non-backward-compatible (i.e., PLaneT major version number other than 1).  Wouldn't requiring them to never break backward compatibility be a deterrent to releasing at all? Or, if they still released, would `dherman`, following the instructions of Racket to create a new package identity for any backward-incompatible version, have given us packages `javascript`, `javascript2`, ... `javascript9`, rather than `javascript` versions `1.x` through `9.x`.<br>
<br>
No-backward-incompatibility might make sense for core Racket (although even core Racket has broken this multiple times), but it's a big deterrent to researchers, and to industry developers who are willing to open source components of their larger systems in lightweight ways.<br>
<br>
Regarding #2, I suggest that should be revisited if #1 is revisited.<br>
<br>
I think PLaneT got both of these a lot closer to right, at least for third-party packages.<br>
<br>
Neil V.<br>
<br>
_________________________<br>
 Racket Developers list:<br>
 <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/<u></u>dev</a><br>
</blockquote></div><br><br>-- <br>Jay McCarthy<br><a href="http://jeapostrophe.github.io" target="_blank">http://jeapostrophe.github.io</a><br><br>           "Wherefore, be not weary in well-doing,<br>      for ye are laying the foundation of a great work.<br>And out of small things proceedeth that which is great."<br>                          - D&C 64:33<br>