search

libgit2 / libgit2sharp.nativebinaries

MIT License
28 stars 62 forks source link

Don't build with STDCALL #86

Closed ethomson closed 5 years ago

ethomson commented 5 years ago

Creating a package built with cdecl instead of stdcall; I'd like to move libgit2 over to all-cdecl, the reason it supports the stdcall option is LibGit2Sharp. It should be easy to update the calling convention attributes in LibGit2Sharp for compatibility.

bording commented 5 years ago

This seems like it would be okay to change, but it does mean that any future 0.25.x maintenance releases would have to have the cdecl changes brought over as well.

ethomson commented 5 years ago

This seems like it would be okay to change, but it does mean that any future 0.25.x maintenance releases would have to have the cdecl changes brought over as well.

In that case, we should strongly consider creating a maintenance branch for that. 🤔

ethomson commented 5 years ago

(I'm surprised we haven't done maintenance branches before, I'm surprised that we haven't had breaking API changes affect us. 🤷‍♂️ )

bording commented 5 years ago

We could do a maintenance branch here, but all of the infrastructure around how the the various assets get collected into the package and then versioned doesn't really have a way to accommodate anything other than an ever increasing 1.0.xxx version scheme, so you'd have a later version of the package being the "maintenance" release.

Since we always lock LibGit2Sharp to a specific version, that won't actually be a problem, but it would result in some odd versions for this package.

ethomson commented 5 years ago

Since we always lock LibGit2Sharp to a specific version, that won't actually be a problem, but it would result in some odd versions for this package.

Yeah, I thought about that. We could bump the new ones so that they were 2.0.xxx where xxx continues to auto-increment. As you point out, it's not completely necessary but it would avoid those weird looking numbers.

bording commented 5 years ago

Yeah, I thought about that. We could bump the new ones so that they were 2.0.xxx where xxx continues to auto-increment. As you point out, it's not completely necessary but it would avoid those weird looking numbers.

That does seem like a reasonable way to handle it. That at least would keep things sorted properly.