Java 为什么运行旧版本不会复制旧行为？

让我换一种说法，以便更直接地把问题的尖端放在这里：Neo4j曾与Roo合作过（也许并不完美，但至少在一本书中发表的一些简单示例显然起到了作用）为什么我不能下载作者使用的Roo版本并复制作者的结果？

当然，一个肤浅的答案是，不属于Roo发行版的软件依赖项已经改变了

更深层次的问题是，为什么会发生这种情况？也就是说，为什么我不能下载向Roo提供这些依赖关系的软件版本，而这些依赖关系在作者撰写本文时是最新的，并且希望能够复制他的结果？

在这一点上，我有点卡住了，我不明白为什么会这样。我似乎无法确定这些版本可能是什么。这似乎应该是Roo配置管理的关键部分。但是，仔细想想，我不记得这种记录保存是典型实践的一部分，除非涉及RPM包管理器。现在，也许我对这一点的看法是完全错误的。但是，如果不是这样，那么在这一点上，进行开源开发的常规方法不需要升级吗？或者我完全错了，可以说，你可以把Roo的时钟倒转过来。如果是这样的话，有人能告诉我如何把它转回去，使Neo4j能像以前一样工作（不管是好是坏，我都不在乎。我只想复制结果。）

这是一种更好的表达和解决问题的方式吗我正在努力支持迄今为止关于Roo的两本书中的一本。坦率地说，我希望看到这本书的作者或出版商介入，帮助我或反驳我，因为这本书仍在出售如果正在进行的示例像我认为的那样严重损坏，那么在我看来，继续销售这本书是错误的，或者至少，在没有向读者发出明确警告的情况下销售这本书是错误的。O'Reilly出版了这本有问题的书，我对他们的商业道德有很高的主观评价——这一评价足以让我怀疑我是否把一切都搞错了

一般来说，如果你错了，你可以依靠100个人来告诉你（再加上10-20分，告诉你你在你做对的问题上是错的，还有5-10分，抓住了一些基本上不相关的问题，显然与你相矛盾，只是为了好玩，而没有任何方式推动讨论——这是一个他们似乎无法理解的合作概念，更不用说遵循了）.但我和其他问过基本相同问题的人只听到蟋蟀的叫声。唧唧唧唧

---

mv（抱歉：我无法立即找到用于标记成员ID的标记语法）问了一个关于Roo对Neo4j的支持的未来状态的问题，这个问题似乎已经失败了。一个相关的问题让我非常困惑——也让我感到沮丧。Neo4j在Roo 1.1.4下得到了支持，但当我尝试在1.1.4最新版本时显然有效的代码时（摘自Josh Long的书《Roo入门》），代码的失效方式与1.2.5（以及即将发布的1.2.6）中的失效方式完全相同。换句话说，可以说，对Neo4j的支持似乎是追溯性地取消的

我的问题是对这一观察的概括：<强>在什么技术环境下（我不想考虑可能的法律原因），它是好的（即，健全的、实用的、必要的？&）追溯软件产品的发布版本的行为？“>/P> 目前，我发现这个关于Roo的决定不太方便，所以我想我可能会忽略做出这样决定的好理由。但是，请注意，我的问题并不是专门针对Roo的。一方面，我不喜欢讨论参与者如何让Roo团队看起来不好。另一方面，我对基因感兴趣ral案例，不仅仅是Roo的特殊案例。事实上，在我看来，行为中没有追溯性的不一致性是健全系统的必要条件。我的意思是，例如，不一致性是在什么时候开始的？是在所述的发布可行性期间还是之后。Pr很可能我戴着我的小鸡帽，但现在在我看来，似乎追溯性的不一致性已经写满了“Humpty Dumpty”

话虽如此，我想我是在偷偷地问第二个问题，但是如果有人告诉我关于Roo的前提是不准确的，我将非常感激；也就是说，Neo4j可以在某种适当的旧版本Roo下使用。在这种情况下，我也会非常好奇如何实现这一点。Roo不需要任何设置配置，因此似乎没有机会进行配置调整。实际上，唯一声明的要求是Linux、OS X或Windows下的JDK和Maven。但是，addon命令显然查询某种数据库。这可能是负责追溯的未声明依赖项不一致的Roo行为

偷偷问了第二个问题后，我发现很难抗拒第三个问题的诱惑。如果我屈服，问题是：在Roo的特殊情况下，如何可能（假设发布代码没有被秘密更改）旧版本的行为已经改变了吗？在我看来，答案必须取决于Roo的依赖关系。但是，假设所有依赖关系都没有追溯性地改变其行为，Roo能在不修改已发布代码的情况下这样做吗？在我看来，它不能，在这种情况下，我非常想知道它是什么中国