<div dir="ltr">Hello,<div><br></div><div><div>As I was updating the package for conda, I came across the issue that the upstream folks actually replace the ldraw parts file in-place, not allowing to retrieve older versions.</div><div><br></div><div>Would there be an interest on your side in maintaining a history of the source tarballs, as e.g. GitHub releases?<br></div></div><div><br></div><div>The size of the compressed parts list is ~45M for the latest version so that should not be a problem.</div><div><br></div><div>Sylvain</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 2, 2019 at 9:14 AM Johannes Schauer <<a href="mailto:josch@debian.org">josch@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Sylvain,<br>
<br>
Quoting Sylvain Corlay (2019-09-13 11:02:17)<br>
> Thanks for maintaining the ldraw debian packages.<br>
> <br>
> I was working on the packaging of ldraw-list for Conda, and checked out<br>
> what you did in Debian for that package.<br>
> <br>
> I noticed that the version number on debian is "1802+ds-1" which is the<br>
> same as ldraw-parts.<br>
> <br>
> In fact, ldraw-mklist has different version number from the parts library,<br>
> which is 1.6. Maybe it should be corrected especially as the ldraw folks are<br>
> looking at separating the two source tarballs.<br>
<br>
thanks for the heads-up!<br>
<br>
Unfortunately, the Version 1.6 is less than the current version of the binary<br>
package 1902+ds-1, so we cannot just change it as otherwise users would be<br>
stuck at the 1902 version.<br>
<br>
My suggestion is that we keep the wrong version in Debian until the split<br>
actually happens. Once it does, we can also create a new source tarball and use<br>
an epoch to get the versioning right.<br>
<br>
Thanks!<br>
<br>
cheers, josch<br>
</blockquote></div>