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.

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

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

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.

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.

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.