Create LibGit2Sharp.NativeBinaries package

bording commented 9 years ago

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

bording commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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.

bording commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

:+1: 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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago