<div dir="ltr"><div>Hi Chris,</div><div>i don't like this change because it looses a very important thing: READABILITY<br></div><div><br></div><div>Monotonicity doesn't count as long as you have a tool that can sort out the ancestry.</div><div>Since we always browse the versions thru some MC tools it's superfluous.</div><div>Monotonicity is mainly for helping us poor humans to quckly identify the relationship between two packages in the graph.</div><div><br></div><div>This is only going to work with 3 to 5 figures in version number.</div><div>With 10 figures, this is ruining our brain and just does not work.</div><div>Please revert or put in inbox purgatory while we have a chance to discuss it.</div><div><br></div><div>As for uniqueness, this is a small problem.</div><div>As long as we have unique ID, then we should use that for storing and retrieving a package.</div><div>The ID is stored in the ancestry, so it's just a matter of using the ID as filename in the backend rather than the ambiguous package name.</div><div>It's more complex because we have to change our servers and protocols, but it would be the right thing to do.<br></div><div>I think that you are doing the easy but and not the right one with your quick and clever hack.<br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 14 févr. 2019 à 05:23, Chris Muller <<a href="mailto:ma.chris.m@gmail.com">ma.chris.m@gmail.com</a>> a écrit :<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 Eliot,<br>
<br>
> > On Feb 13, 2019, at 7:13 PM, Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> wrote:<br>
> ><br>
> > What are the two most-important properties we want from our<br>
> > versionNumber?  Monotonicity and uniqueness.  The current scheme only<br>
> > provides the former, this uses DateAndTime now utcMicroseconds to<br>
> > provide the latter, too.  As a bonus it also happens to encode the<br>
> > save timestamp into the VersionName, so available without having to<br>
> > open the file.<br>
> ><br>
> > I admit it looks intimidating given what we're used to seeing, but<br>
> > what of the added safety and utility?<br>
><br>
> It is trumped by the illegibility.<br>
<br>
Not as bad as it appears, since the high-order digits will be the same<br>
between version #'s, plus, second-resolution should be sufficient, so<br>
versions in a list would actually look like this:<br>
<br>
    Monticello-cmm-1550203798<br>
    Monticello-cmm-1550117398<br>
    Monticello-cmm-1550030998<br>
<br>
Whilst still retaining all of the utility.  Maybe even a setting in<br>
the tools could hide the high-order digits in the UI if we wanted...<br>
We're already into 4 digits in our version #'s anyway so....<br>
<br>
> When was the discussion around this change?<br>
<br>
You're participating in it now.   :)<br>
<br>
There was another change to earlier today that you may be interested<br>
in asking that question about too, since it changed 19-year old<br>
SequenceableCollection>>#= with a one-day old replacement and actually<br>
went into trunk.  This one is in the Inbox.<br>
<br>
> I’ve been out if things (apologies) but I find this change quite horrible.<br>
<br>
I understand this initial gut reaction, but I hope you'll think and<br>
sleep on it, and help think about the problem and some alternative<br>
solutions you like better.  VersionName uniqueness is important for<br>
the Monticello model.<br>
<br>
Best,<br>
  Chris<br>
<br>
</blockquote></div></div>