[Libusbx-devel] Keeping the 1.0.9rc3 tag

[Michael Plante]

Pete Batard wrote:
>> Michael Plante wrote:
>> > You keep saying "mainline" like that's only one branch.  It's not, or
at
>> > least it wasn't with Peter.
>>
>> It is. It's the only one that will ever see official releases.
>> Other branches we care about will either have different major/minor (eg.
>> 2.0) or, if based on mainline, an offset.

I guess what I mean is that "master" can have HEADs over time that are not
direct ancestors of one another.  Both are still "mainline" because they
were both the tip of "master" on the "mainline" repo at one point in time.


>> Please define "maintainer".

You, and anyone else who can push to the official repo.  I can't remember
who that is.  For libusb it was Daniel and Peter.  Do you disagree with this
definition?  I didn't think I was making up any new terminology here.



>> >>> "being able to know *exactly* which commit the library came from,
even
>> >>> if built from git, if generated against mainline (if not, then it's a
>> >>> fork, and since anything can happen in a fork, of course we don't
care
>> >>> about version conflicts there)".
>> >
>> > I did read that, and it is wrong.
>>
>> Ah, yes, there's "right" and "wrong" and, of course, you are the judge.
>> Beats having to provide verifiable evidence of an allegedly better
>> solution, doesn't it?

When you move the evidence farther down, it sure looks that way, doesn't it?
Clever.


>> > You are repeating yourself for nothing.
>> > You can't even tell if a log file came from a forked version.
>>
>> Why would I want to?

So you can tell if you want to support it or not.


>> We can not solve this problem
>> unless the fork uses git and people diligently apply our pre-commit
>> hook.

I don't think pre-commit will work, since the hash is not yet known.  It
might have to be part of the build script (which would have to fail
gracefully if git's not there), or perhaps it could be post-commit and go in
an ignored file (though ignored files are risky).  People who aren't using
git are presumably also people who know where they got it from, so that's
not really in line with that part of your original reason that I was trying
to help with.


>> > Your whole
>> > stated point with this thing was that users can't tell us where they
got the
>> > version they're using from.
>>
>> Because it is IMPOSSIBLE to get that data if they fork.

I didn't say "fork".  Please read the words.  I am assuming they just
grabbed a tarball and closed their browser and don't remember where it came
from.  Most such tarballs probably will come from git, and likely from one
of us (not all, but most, which means solving the problem MOST Of the time).
Anyway, if it's "impossible" (it's usually, in fact, possible), why was it a
primary goal of yours?


>> 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?


>> Please cease to think that I gave this problem 5 minutes thought and
>> went with whatever I liked or that I thought could easily be reused.

I think that you are unaware of anything other than a linear history, and
have therefore missed why the distance thing is insufficiently general.


>> > That said, if we only use one, only the hash gives us all information.
You
>> > *can't* look up the distance and get a hash.
>>
>> I can against mainline, which is all *we* care about here, especially as
>> there is no sure way to prevent versioning conflicts with forks, unless
>> we *force* people to use git as their VCS as well as our versioning
>> system.

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.


>> Given that there is no versioning scheme that can help us
>> identify for sure whether libusbx came from a fork or from mainline,
>> especially if git is not used on the fork, you still seem adamant to
>> want to force us to care about forks for some weird reason.

It can tell us for sure that it came from a fork, but can't tell us for sure
that it came from mainline.  That is still helpful, because most of the time
that it does tell us it came from mainline, it will be true.  Your increment
method will do none of the above.


Regards,
Michael