Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How do we pack and release? #158

Open
JohanLarsson opened this issue Oct 24, 2018 · 17 comments
Open

How do we pack and release? #158

JohanLarsson opened this issue Oct 24, 2018 · 17 comments

Comments

@JohanLarsson
Copy link
Member

There has been some work done and we should release a new version. I'm not familiar with the scripts so don't know how to pack and release.

We should update so that the scripts produce the analyzer package and adds it as a dependency to the library package as it has fixes for things we made obsolete and breaking changes.

@cdrnet
Copy link
Member

cdrnet commented Oct 29, 2018

Yes, this needs to be documented like in Numerics - but up to date.

In Numerics, creating a release is essentially:

  • Add release notes entry in RELEASENOTES.md.
  • Run ./build.sh all sign strongname (sign enables code & package signing (A), strongname to also create the strong name packages)
  • Create actual release commit (as the build has updated a few files - this can also be done beforehand by running ./build.sh prepare once after updating the release notes)
  • Publish by running ./build.sh publish, which does:
    • create release tag and push it to github
    • publsh NuGet packages to the public gallery
    • publish API reference to the website repo (B)
    • publish website to the website repo (B)
    • publish original nuget packages and zip file to the archive (C)

Unfortunately the following aspects currently bind this to me:

  • (A) Code and package signing is all or nothing in NuGet, therefore all packages need to be signed with a code signing certificate. We can configure multiple certificates in the gallery, but the one creating a release must have such a (usually non-free) certificate.
  • (B) There is an (automated) extra step involved here for the actual deployment which uses a mechanism I cannot easily share, as we're not hosting on GitHub pages yet. However, skipping this would not block the release, just cause the website to be outdated for a while.
  • (C) Currently on private OneDrive, although I'm considering to just push them to the website instead. Again, skipping this would not block the release, just cause the archive to be incomplete for a while.

B and C we can fix or work around.

Regarding the analyzer packages: yes, but I think the highest priority first is to be able to create and publish new packages in the first place - at least prerelease once.

@JohanLarsson
Copy link
Member Author

The analyzer has code fixes for things we made [Obsolete], mostly convenience but still nice if we could pack & publish with the dependency.

@Jones-Adam
Copy link
Contributor

well if you merge in #155 it would be safe enough for a prerelease build which supports .net standard, running build.sh publish works as far as I can test

@JohanLarsson
Copy link
Member Author

@crdnet can you review #155? I don't know this stuff well enough to review.

@cdrnet
Copy link
Member

cdrnet commented Nov 18, 2018

I finally upgraded the build framework and release a new beta. Before we do a proper release (without beta prerelease tag) we should have a look at how to package the analyzers properly.

@cdrnet
Copy link
Member

cdrnet commented Nov 18, 2018

It seems I've missed to notice unexpected package references in the resulting NuGet package - tracked in #161.

@JohanLarsson
Copy link
Member Author

JohanLarsson commented Nov 18, 2018

I can help with packaging the analyzers.
We want a structure like:

/analyzers
  /dotnet
    /cs
      Mathnet.Spatial.Analyzers.dll
<developmentDependency>true</developmentDependency>

And the analyzer package should have no dependencies. The dependencies are provided by Visual Studio or MsBuild.

@li0nsar3c00l
Copy link

Whats the reason for keeping the nuget references in seperate files?

@cdrnet
Copy link
Member

cdrnet commented Nov 21, 2018

@li0nsar3c00l are you referring to the fact that there are two paket.references files instead of just one? Or that there is a paket.references file in the first place? Or something else?

@li0nsar3c00l
Copy link

I am referring to the fact, that this repository is using a packet reference file in the first place instead of adding them directly to the project file. This seem to lack proper suport for asset exclusion, especially regarding #161

@cdrnet
Copy link
Member

cdrnet commented Nov 22, 2018

Ah, that's supported just fine. I've just closed #161 with a fix.

@li0nsar3c00l
Copy link

li0nsar3c00l commented Dec 3, 2018

Nice to see! Are the build artifacts pushed to somewhere like myget?

@SkinnySackboy
Copy link

Thanks for this guys, I’m looking forward to the officialised .NET standard version.

@li0nsar3c00l
Copy link

Any Chance you can push the current build to nuget?

@Isitar
Copy link

Isitar commented Jan 7, 2019

any update when you release a new beta build to nuget without StyleCop in it?

@SkinnySackboy
Copy link

Any idea when the current beta version will be made official?

@jkalias
Copy link
Member

jkalias commented Mar 29, 2023

Hi @cdrnet ,

Could you please create a todo list similar to Numerics which someone else than you can process? I'd love to keep the library up to date

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants