Create and deploy a Nuget package #12
Conversation
|
Hello! thanks for the contribution! I'll wait a few days if anyone has anything to say about the PR, then I'll merge it! Personally, I don't have interest in becoming the owner of the package; I keep this repo up to date with compiler updates and add some seldom fixes, but unfortunately the project is pretty much abandoned at the moment. Just a question: how come the nuget version is 1.5.3? Is that related to the 1.5.0.0 used in the master? Or are these unrelated? I mean, if this repo ever gets at 1.5.3.0 what would happen? |
|
Hey,
Good point about the versioning, I wasn’t sure about that either.
The package version should be specified in the appveyor file, which then adds the current build number, currently 3.
So I’ve just set it to 1.5, leading to 1.5.3, but we could set it to 1.5.0, which would give us 1.5.0.3 in this case. It couldn’t be 1.5.0.0 though as 4 components is the max and the last one should be free to move whenever any aspect of the package is changed, e.g. adding language files, etc. This is why I think it’s good adding the build number and three version components are probably enough to describe how the library changes (major, minor, patch). What do you think ?
Concerning ownership of the Nuget.org package, I’m happy to keep it but I’d still have to pm you an API key which you’d have to encode through your appveyor interface and replace the the key in the appveyor.yaml when merging my pull request. This will allow your builds to get published straight away.
From: QbProg <[email protected]>
Sent: 04 December 2018 20:57
To: QbProg/crashrpt2 <[email protected]>
Cc: HERMS Paolo <[email protected]>; Author <[email protected]>
Subject: Re: [QbProg/crashrpt2] Create and deploy a Nuget package (#12)
Hello! thanks for the contribution! I'll wait a few days if anyone has anything to say about the PR, then I'll merge it! Personally, I don't have interest in becoming the owner of the package; I keep this repo up to date with compiler updates and add some seldom fixes, but unfortunately the project is pretty much abandoned at the moment.
Just a question: how come the nuget version is 1.5.3? Is that related to the 1.5.0.0 used in the master? Or are these unrelated? I mean, if this repo ever gets at 1.5.3.0 what would happen?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#12 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ArHIA3ckKc8-wCFU7eSheAZVnTBAaMySks5u1tObgaJpZM4Y-izd>.
|
|
Thanks for working on this. Would creating a GitHub organization solve some of the issues with the ownership of the package? In that way we could divide the work among the people interested in the project. Looking at the SVN logs on Sourceforge, it seems that @AndreasSchoenle also contributed earlier. Maybe he could share his views on this as well? Other things to consider:
|
|
The major.minor.version.build versioning scheme seems fine to me but we do not use Nuget and at the moment we use binaries compiled from our fork, so I have no real stakes in this discussion. Whether or not to create a GibHub organization I believe to be entirely up to @QbProg, who has put in the successful effort to collect, align and merge contributions from different forks so far. If he/she is willing to continue and reasonable PRs get accepted upstream from the various forks, I see no problem either way. As to CrashFix, there seem to be a few imports on GitHub already, e.g. at https://github.com/0um/crashfix,https://github.com/xyzz/CrashFix and forks thereof, that have seen bugfixes and enhancements. On first glance they do not seem to share a lot of work beyond the initial import. Thus, it seems like many users of CrashRpt largely roll their own report analysis, integrating with their version control system, their specific build and deploy mechanism, server infrastructure and their product versioning scheme and with regression tests specifically tailored to their setup. I imagine many of them do not use CrashFix at all, as the main task is to analyze a minidump and organize reports in a way that is meaningful to developers. This task is not really tied to the specifics of what CrashRpt does. Therefore, I would argue to consider CrashFix a separate project with separate repositorie(s). Personally, I am not using most of the CrashProbe API during analysis and would not mind to reduce its scope to just extract the information specific to CrashRpt and a minidump. The Minidump reader itself could then be moved to CrashFix or any other analysis project. |
|
indeed, I don't see any advantange in having the build number in the version, as Patch releases are good enough. We could use the build number to packaging/nuget as @p-softway suggested. There's a lot of work that should be done on this project, as @jowr pointed, but without a proper server , the crashrpt tool is almost useless. I personally thinking of abandoning it as I was not able to put a reporting/analytics solution up quickly, which supports nicely 64bit. In my view, it would be more useful to make it work with a server of a different solution, but could not find any suitable. |
Hi,
As I needed your library in a project using nugets, I thought it was a good idea to publish it on Nuget.org.
The package is now listed as CrashRpt2.CPP created from my Appveyor project.
This currently works with an API key from my Nuget.org account that I just set up which is encoded for my Appveyor account. If you agree to merge this into your repo I'll add you as an owner of that package so you can replace that key with your own.