-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Update version number to 1.4.1 and other changes in prep for release of new NuGet packages. #2435
Conversation
LGTM, do we want to also generate/publish the other NuGet packages? |
I think we should publish at least the .NET-targeted package in addition to the Native package at this time. The packages for Symbols and individual flavors might be overkill at this time as they don't necessarily unlock any new dev scenarios, but they might be helpful for some as an optimization (low-bandwidth or low-disk environments). @EdMaurer @digitalinfinity @aruneshchandra What do you think? @boingoing If we do publish multiple packages, I think we should defer to the wisdom of letting our primary package name be the .NET-targeted package since that's what NuGet users would generally expect. The native package (vc140) could be our secondary feed. In that case, the names and ids of the nuspec files can remain as they are. |
@boingoing Do you think distributing ch.exe in our NuGet package actually makes sense? Maybe we should let that simply be a part of the GitHub zip publication. ch.exe doesn't serve any purpose in the dev process and 6 * ch.exe + ch.pdb bloats the extracted contents of the native package by a fair amount (5 MB each = 30 MB), but the package itself (a zip was only reduced by about 5 MB total by removing ch.exe + ch.pdb from each flavor). See dilijev/ChakraCore@nufeed...dilijev:nufeed-reduced for reduced spec. |
@pre10der89 @matthargett NuGet version 3.3.0 complains of the following for the .NET-targeted package:
Is that expected? |
'netstandard' moniker replaced 'dotnet' in NuGet 3.4 RC, which was distributed last year with VS2015 Update 2: If NuGet 3.3 compatibility is needed by others (we don't need it for our purposes), I guess dotnet5.0 could be used, or portable-win81+wp81 which maps to netstandard1.0 according to the table at the above URL. Given that we're packing vc140, which would seemingly require VS2015, I'm not sure requiring NuGet 3.4 it too much of a problem? Also, am noticing that several of the vc140 boost NuGet packages mention VS2015.3 in their description. |
we only put ch.exe in the new package because it was in the old package. The old package was more of a binary distribution than anything else, since it couldn't be referenced to satisfy project dependencies. We don't need ch.exe for our purposes, and the smaller download size would make for a better initial developer experience when people clone and build the Net46 versions of React Native Windows, CodePush, etc. |
@matthargett Thanks for the clarification. We originally set up a feed for preview packages and hacing ch.exe there made sense in that context. Not sure that reasoning holds up anymore as we're not really publishing preview packages, and even if we resume publishing preview packages, they will be for the NuGet dev experience. I think it's fine for us to say if people want to have ch.exe they could build it or pick it up from the GitHub release page. Even so, for now, not removing ch.exe from the package is a reasonable default action, pending further discussion. For the record, the sizes are: |
@matthargett I was wondering if it was just that my nuget.exe was out of date. There's no particular reason to support older versions. |
@matthargett @pre10der89 You can find the preview packages on myget at: https://www.myget.org/feed/chakracore-preview/package/nuget/Microsoft.ChakraCore and https://www.myget.org/feed/chakracore-preview/package/nuget/Microsoft.ChakraCore.vc140 |
Tested in react-native-windows master and our react-native-code-push branch on Win7/x86, both worked fine. 🎉 I'll test on Win10/x64 tomorrow and see if @pre10der89 or @abodalevsky find any issues as well. Looking good so far, though! 😃 |
See #2266, #85