<div dir="ltr"><div dir="ltr">Hi Christoph,</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div id="m_-1228838674167061375m_-4906735757957191006m_-6277375686952882493divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><p>From the perspective of someone who has only gotten to know SqueakSource from the client side: The possibility to enumerate *all* trunk versions is important for me in several situations. </p></div></div></blockquote><div>Would you mention or describe one or more of those situations, because...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div id="m_-1228838674167061375m_-4906735757957191006m_-6277375686952882493divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><p>It would be quite a shame if one could no longer access the full ancestry
 of a version or browse an ancient version of any package through the UI. </p></div></div></blockquote><div>... this change would not affect the above use cases.  They could still be accomplished via the "History" button, because it accesses those very old versions *directly*, by name or UUID.  What we're talking about here is just the "list of files", NOT the list of ancestors, which we still have.  The lists in the Repository browsers wouldn't show everything in the ancestry, but the ancestry is a better place to review that anyway.  I'm not convinced there is _any_ use case that needs a list of *all* Repository files (Versions) since the beginning of time.  If there is one, it's on an eternal linear degradation path, and some alternative approach should at least be considered. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div id="m_-1228838674167061375m_-4906735757957191006m_-6277375686952882493divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><p>The release notes generator in the ReleaseBuilder could also be affected, I think.</p></div></div></blockquote><div>It shouldn't be.  As above, it's in the ancestry.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div id="m_-1228838674167061375m_-4906735757957191006m_-6277375686952882493divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif" dir="ltr"><p><span style="font-size:12pt">With a view to modern REST and GraphQL APIs, would it be possible to add support for some parameters to the requests in question to enable pagination or filter the retrieved information vertically (i.e., leave out some metadata)?</span></p></div></div></blockquote><div>I'm sure it is, but right now I'm just looking for TSTTCPW for getting trunk development back online.  I think the round-robin with date-based balancing sounds like a good possibility for something that could be done quickly.</div><div><br></div><div>Best,</div><div>  Chris<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div dir="ltr"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div></div>
</div>
</blockquote>
</div>
</div>
</div>
</div>

</blockquote></div></div>