[Libusbx-devel] Keeping the 1.0.9rc3 tag

[Pete Batard]

On 2012.03.26 02:14, 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.

Else, how exactly do you define mainline?

> You may manage to keep it that way if you take
> control the same way Peter did.  That was my point about multiple
> maintainers -- not everyone has the same narrow approach to version control.

Please define "maintainer". The only maintainers libusbx needs to care 
about are the ones that commit to mainline, because anybody else doesn't 
commit to libusbx, they commit to their own version, with is 
libusbx-<your-name-here>. Thus I don't expect more than 2 or 3 people at 
any one time to qualify as libusbx maintainer (else we're asking for 
trouble).

Now, if your "maintainer" is the very "wouldn't it be nice if I could 
make libusbx solve my versioning issue?" person who is going to maintain 
their own personal fork of libusbx and produce their own releases, 
you're barking at the wrong tree here.
For all I know, the "maintainer" of a libusbx branch can use svn, 
mercurial or any other VCS instead of git. Should that mean we should 
drop the idea of automating our versioning in a pre-commit hook and just 
do our versioning manually then, because otherwise whatever we do will 
not help these guys? Or do such "maintainers" not have the freedom to 
use whatever VCS they want?

By definition anybody who forks has the freedom to do whatever they 
want, including, even if we were to somehow come with a scheme that 
allows us to differentiate forks by default, modifying their fork to 
provide a version that conflicts with mainline.

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

> 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? Please see above. We can not solve this problem 
unless the fork uses git and people diligently apply our pre-commit 
hook. Does that mean people who fork libusbx MUST use git and follow 
what we tell them to do? That sounds very restrictive from us.

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

Here, consider this scenario: someone picks up mainline, and add stuff, 
and they're not using git. Please find a sure way to get a version 
scheme in their fork that will tell us that they're not using mainline 
any longer?

>>> Also, as I already explained at length, using hashes is problematic,
>>> because you have to do a lookup to tell what version comes before or
>>> after another.
>
> We can use both.  (Just another example of something I'm repeating.)

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.

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 
did try to consider all variables such as the fact that people may not 
use git on a fork, or that we'd like our versioning scheme to work with 
Windows deliverable outside of running a libusbx app, or that there's a 
much greater chance when someone provides a distance instead of a hash 
for a maintainer to be able to say "oh right, I remember #1234 was the 
one that introduced a specific feature" even if they don't have access 
to a git tree.

All you're coming from so far is "your idea is no good (because it won't 
help with the versioning in my fork). Maybe if I say, without proof, 
that libusbx could use a different versioning, I'll get something that 
can solve *my* problem."

Regards,

/Pete