[Libusbx-devel] Keeping the 1.0.9rc3 tag

[Michael Plante]

Pete Batard wrote:
>> Michael wrote:
>> > I guess what I mean is that "master" can have HEADs over time that are
not
>> > direct ancestors of one another.
>>
>> Yes, and I addressed that point. The only HEAD that matters is the one
>> from mainline.

We're going in circles here.  They're both "mainline".  Ok, so you plan to
allocate a ton of offsets.  You say 65.  Maybe that's enough.


>> > People who aren't using
>> > git are presumably also people who know where they got it from
>>
>> How convenient. "*I* have decided that people (non git users) who are an
>> annoyance to my solution don't matter".

Not what I was saying.  More clearly, people who are not using a version
identical to a version in git.  Not whether or not they're using git itself.
I.e., people who have modified it know where they got it from.



>> >>> No we can't, unless you want to make the version reported by the DLL
>> >>> differ from the actual version of libusbx (and I think you should be
>> >>> aware that we probably wouldn't mind if someone can just right click
on
>> >>> their DLL without running anything, and report what they see). We
have
>> >>> only 16 bits for the nano due to Microsoft's versioning constraints.
So
>> >>> it's either a 4 hex hash or a 0-65535 integer.
>> >
>> > So you can't put it in the version number.  And?
>>
>> Not at all. I can put a distance there no problem at all, even planning
>> for offsets. We're not going to have more than 65536 commits for each
>> major.minor.micro, and if we ever go over boundaries we set, as long as
>> we have switched micro, we can "reset" the distance, so we could
>> probably work within a a [0-999] window for the nano, and still be fine.
>> Hashes on the other hand, are more problematic, as there's a 1 in 65536
>> chance you will get a collision if you only use the first 4 digits, to
>> be able to let users find the version from the DLL properties.


That's what I said.  You can't put the hash in the version number.  So what?
Put it elsewhere.




>> On the contrary, I think you are inventing excuses to pretend the
>> distance cannot work with non linear history, when I have provided ample
>> evidence it can. A tree just requires a system of x,y coordinates, and
>> we could easily provide such a system with (y*1000+x), with each fork
>> being a new y. Unless you count on libusbx maintaining 65 semi-official
>> branches at once, non-linear is really a non-issue. And I'm pretty sure
>> we'd be fine even if we went with (y*10000+x), which is way more than
>> we'd need not to have to reset the nano. At the very least, a 10000
>> range is what I want for mainline, just in case.


I'd rather not have to deal with the manual coordination of agreeing between
ourselves who has which offsets when hashes handle it fine automatically.



>> > Your increment won't work there either, so that's not valid for or
against.
>> > And no, it won't work against "mainline", in general, which was my
original
>> > point.
>>
>> Then do a better job at proving it, rather than saying "it won't work".


With manual coordination of offsets between developers, as you just
described above, it can work.  It's still an unnecessary pain and people
have to actually RECOGNIZE that it branched, which is not always obvious.
Additionally, if anyone disagrees about who gets what offset (say they go
offline to develop for a few days), all those commits have to be amended or
it fails.  We all know how you hate amending commits.  Why not let it get
handled automatically?



>> > That is still helpful, because most of the time
>> > that it does tell us it came from mainline, it will be true.
>>
>> Ever heard about "false sense of security".
>> Because this is EXACTLY what you are advocating.
>>
>> You want us to go with a solution that will tell us "most of the time"
>> if something came from a fork. Except, we will never be 100% sure it is.
>>
>> Wanna take a bet? As a maintainer, I sure won't, ergo, even if we had a
>> 99% chance of figuring out whether a specific libusbx version came from
>> [...]


Risk vs cost.  The cost of supporting something we hadn't planned on
supporting for one type of error, or the cost of sending someone away that
we should have supported for the other type.  I don't see either of those as
life-shattering events.  Your percentages are unconvincing.



Regards,
Michael