Create LibGit2Sharp.NativeBinaries package

[bording]

Recreating PR #1 from a branch on the upstream repo instead of my fork.

[bording]

@nulltoken So as best as I can tell, I've done everything I need to, but I'm stil not getting access to the secure variables. Neither of the travis builds that fired from the branch push and the new PR are seeing them.

The build logs are showing TRAVIS_SECURE_ENV_VARS=false still.

Hmm.

[carlosmn]

Secure vars are disabled for external pull requests. In order to gain access to them, you'll have to push to this repo and create the PR between your branch here and master.

[bording]

Right, that's what I did with this new PR. It has been created from the bording/addStuff branch on the main repo, not my fork.

[nulltoken]

@carlosmn Could you please check I provided @bording with the correct key, please?

[nulltoken]

@bording Oh, I may have something. Following travis-ci/travis-ci#2820 (comment) led me to this BanzaiMan/travis_production_test@d24c694 where one can see no dash ("-") before the secure key.

[nulltoken]

Just pushed a fixup to test this idea out. Let's wait and see...

[nulltoken]

Hmmm. I eventually had to remove the secure variable from the travis build script and defined the key in the repository settings.

Now we've got a nice $ export BINTRAY_API_KEY=[secure] in the build log 😉

[nulltoken]

And... we've got something at https://bintray.com/libgit2/compiled-binaries

[bording]

Awesome. I'm still not sure what needed to change to get the secure var working as intended, because as far as I could tell from the docs I had it set up correctly.

Setting it directly in the repository settings works just as well, so I guess we won't worry about it!

[bording]

Now that we've got Travis working properly with bintray, the last remaining this is to figure out how to handle the package versioning, and update appveyor.yml appropriately.

[bording]

@nulltoken Looking at the packaging versioning situation, I see three possible options:

Option 1: Track the libgit2 version

In many ways this is the option that makes the most sense, since this package is just a bundling of the native library. However, this is too restrictive since we'd then be locked into just releasing this to line up with the officially versioned libgit2 releases.

Option 2: Track the LibGit2Sharp version

This is more or less what the PR is doing now. We would build prerelease versions of the package to go with the prerelease versions of LibGit2Sharp. The benefit of this is that the version numbers of the official packages line up nicely, e.g. LibGit2Sharp 0.22.0 depends on LibGit2Sharp.NativeBinaries 0.22.0

However, the downside of this approach is more manual work to keep the versioning synchronized. Whenever LibGit2Sharp's version is bumped, the appveyor.yml of this repo has to also be changed to match. That's not too bad, but the bigger issue is that when it's time to release a new official version of LibGit2Sharp's package, the current prerelease NativeBinaries package will have to be rebuilt/reuploaded in advance just to have the correct official version number. That then ripples back to the LibGit2Sharp repo, where you have to update packages.config for the new NativeBinaries package number.

Option 3: Make the version number independent

This option completely decouples the version number from everything else. I would alter the appveyor.yml to something like

version: 1.0.{build}

and then we never worry about the version number again. Whenever a new version of libgit2 is needed, the repo just gets updated and we get a new package with whatever the version happens to be and LibGit2Sharp gets updated accordingly. We can keep the prerelease tag for any non-master builds if we want, which could be useful.

---

Since option 1 isn't viable and because the NativeBinaries package isn't intended to be used directly by people (making it less important for the version number to convey meaning), I'm leaning towards option 3.

Thoughts?

[nulltoken]

I'm leaning towards option 3.

I'd agree with this. @ethomson @jamill @Therzok Thoughts?

We can keep the prerelease tag for any non-master builds if we want, which could be useful.

I'm not sure about this. What would be a non-master build?

[nulltoken]

I'm not sure about this. What would be a non-master build?

Sorry. I realize that my question was badly worded. Let me try to elaborate further on my thoughts and see and I can share in a better way my current state of mind.

• I think this repo will only contain one branch, master (Hence the question about the non-master build)
• The way the NuGet package is made, LibGit2sharp will surely be the only consumer of the NuGet packages produced out of it. So the versioning scheme can be more or less tied to our needs.
• Months may be passing before libgit2 reaches 1.0. And would it reach this point, we may still decide to still keep on building against libgit2/master. Thus, every build can be seen as either a perpetual prerelease (from the libgit2 standpoint) or a "stable" one (from the LibGit2Sharp standpoint).

Given this, we could even refine further Option 1

• 0.21.{build_number} -> current version of libgit2 (including everything that has been pushed to master)
  • Not that complex to update the version prefix when that's required
  • Doesn't convey that it's really more than a pure 0.21
• 0.22.{build_number}-preYYYYMMDDHHMMSS -> prerelease to the potential libgit2 next version
  • Clearer than the previous proposal
  • Dangerous as libgit2 have skipped versions in the past and we don't really know the next version of it until it's released (/cc @carlosmn)

Option 2 comes with too many downsides in my opinion

Option 3

• 1.0.{build_number} -> None of the above
  • Independent. Decoupled.
  • Impossible to understand what's the real libgit2 binary we're linking to

Currently, I'd prefer to go with 0.22.{build_number}-preYYYYMMDDHHMMSS as it's the more meaningful one. However, I'm not against 1.0.{build_number} as it would require no maintenance as all.

[bording]

I'm not sure about this. What would be a non-master build?

The scenario I was thinking of is when you're testing to see if updating to a new libgit2 version fixes a problem before actually making the change. I believe I've seen some branches in the main repo like this before. The easiest way to do this would be to create a test version of the nuget package to try it out, and if you want linux and osx builds also, the simplest way to get them would be to let the CI systems build a package.

Of course, you wouldn't need to push this test package up to nuget.org, you could just test it locally, but have a -pre tag on the package automatically might be helpful here.

You could also skip the CI step altogether for this and run buildpackage.ps1 locally.

So, not super important, but I've already got the support for it in the scripts.

[bording]

• I think this repo will only contain one branch, master (Hence the question about the non-master build)
• The way the NuGet package is made, LibGit2sharp will surely be the only consumer of the NuGet packages produced out of it. So the versioning scheme can be more or less tied to our needs.
• Months may be passing before libgit2 reaches 1.0. And would it reach this point, we may still decide to still keep on building against libgit2/master. Thus, every build can be seen as either a perpetual prerelease (from the libgit2 standpoint) or a "stable" one (from the LibGit2Sharp standpoint).

👍 This lines up with everything I was thinking.

0.21.{build_number} -> current version of libgit2 (including everything that has been pushed to master)

An additional problem I see with this is that it doesn't fully track the libgit2 version number as found in the version header, which lists a revision and patch version that we'd be ignoring. If we're building more often than that file changes (and they tag a new release), then package version numbers aren't useful for determining the libgit2 version.

0.22.{build_number}-preYYYYMMDDHHMMSS -> prerelease to the potential libgit2 next version

In addition to having to predict the future version number for this work, we also run into that NuGet viral prerelease problem. The LibGit2Sharp packages would have to be prerelease also if we depend on a prerelease binary package.

[nulltoken]

In addition to having to predict the future version number for this work, we also run into that NuGet viral prerelease problem. The LibGit2Sharp packages would have to be prerelease also if we depend on a prerelease binary package.

Dammit! I (once again) forgot about this :/

Long live 1.0.{build_number} then!

[bording]

@nulltoken Ok, with the package version decided on, I think this is ready to go!

I'm assuming you'd prefer this get squashed down to a single commit?

Once we get this finished, the next step is to get an actual package up on nuget.org. Then I can update my PR on the main repo to use it instead of my test package, and it will be ready to merge also!

[nulltoken]

I'm assuming you'd prefer this get squashed down to a single commit?

Yes, please 🙏

Unless anyone has any further comment, it looks like an amazing piece of engineering ready to be merged in.

[shiftkey]

[bording]

Squashed and ready for merging!

[nulltoken]

"Merge into master" build logs were

• https://travis-ci.org/libgit2/libgit2sharp.nativebinaries/builds/62531651
• https://ci.appveyor.com/project/libgit2/libgit2sharp-nativebinaries/build/1.0.25

Downloaded

• AppVeyor artifact from https://ci.appveyor.com/project/libgit2/libgit2sharp-nativebinaries/build/1.0.25/artifacts
• Travis 0.22 artifacts from https://dl.bintray.com/libgit2/compiled-binaries/

Opened the downloaded AppVeyor package with NuGet Package explorer

• Extracted the bintray archives and moved them into the proper locations

Pushed the resulting package to NuGet gallery

• https://www.nuget.org/packages/LibGit2Sharp.NativeBinaries/