Brooke --<br><br>I don&#39;t even think we&#39;re talking about the same thing anymore.&nbsp; Versions will differ, and if you prefer an old version for its featureset or the specific implementation of a given feature, then stick with that version or please work to port the code over.&nbsp; No substantive feature has been deprecated capriciously.&nbsp; Indeed, bugs are sometimes introduced with new architectures and compromises between competing designs can alter requirements, interfaces or functionality.&nbsp; But this is normal to any developing project.<br>
<br>The point was already settled in the other thread that aspects of the HLT acquisitions implementation in question never made it to mainline Koha.&nbsp; As far as that goes, it was not &quot;broken&quot; or taken out: it was never there.&nbsp; So we&#39;re not talking about the same thing.&nbsp; I don&#39;t blame Katipo or Chris or HLT or anybody else, because managing customizations vs. mainline code can get complicated, especially using the version control systems of that time, with limited professional and community resources, etc, etc.&nbsp; <br>
<br>Similarly, I&#39;m not going to argue LibLime&#39;s business practices to you in this or any other thread.&nbsp; In the end, for the Koha project, the best code coming in wins.&nbsp; I have yet to see a situation where code that was better for *all* Koha users was rejected in favor of inferior code.&nbsp; It doesn&#39;t matter who wrote it, or whether they were paid, by whom, or how much.&nbsp; This includes situations where my own code was rejected as inferior!&nbsp; <br>
<br>--Joe Atzberger<br><br>