> On Feb 14, 2019, at 1:07 AM, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> 
> Hi Chris,
> i don't like this change because it looses a very important thing: READABILITY

+1.  And memorability; impossible to remember these accurately.  And writability, for the same reason.


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