Reactive: Ship Rx/Ix 3.0

Created on 16 Jun 2016  路  24Comments  路  Source: dotnet/reactive

This issue is meant to serve as a checklist for shipping Ix and Rx 3.0.

  • [x] Update licenses to .NET Foundation. NuSpec's and source files. Also fixes #23 (Oren)
  • [x] Sanity check latest packages against all supported project types. Ensure NuGet's can be installed and correct versions are referenced
  • [x] Set up authenticode signing infrastructure (Martin)
  • [x] Authenticode sign final version
  • [x] Update Go Links in nuspecs (Martin)
  • [x] Set up CI build (Oren)
1 - Working [area] Ix [area] Rx

Most helpful comment

The final signed 3.0 binaries are on the MyGet feed and will be live on NuGet.org on the 27th.

All 24 comments

Note that the builds all show an NU1007 warning. This is a bug in the CLI tools and is tracked here:
https://github.com/dotnet/cli/issues/3381

@onovotny we should at some point start splitting out Ix and Rx into two separate repos so we can version them separately.

@mattpodwysocki that would seem to best fit in with moving to the ReactiveX org. The only downside is potentially losing history.

I can also see an option: push this repo to both the new Ix and Rx repo and then delete the corresponding directories in the destination.

@onovotny I think we should do it sooner rather than later. Yes, that was the biggest issue when dealing with this before was to tease out the history for each commit whether it be for Ix or Rx when we went to GitHub in the first place

When we decide we want to do that, I could probably rustle up some git filter-branch magic that would give us a new repo of just the IX and RX trees with history for those folders. But let's ship a signed 3.0 first :)

+1 on doing it aligned with the org move. That would make it clear as we'd have to force push otherwise.

@martinwoodward that could be slick. Yeah, I think we can/should do it just after shipping 3.0. Are there any magic tools for moving issues or do we just manually copy/reference them?

No magic there I'm afraid. We'd probably just reference - use the move to make a clean start and pull over the essential issues.

@martinwoodward sounds familiar when we moved from Codeplex...

Is there any reason to have requireLicenseAcceptance on the NuGet package set to true anymore?

@onovotny no, that was because we had a custom license. We should be Apache 2.0 all the way around

Should authors remain as Microsoft or also move to .NET Foundation and Contributors?

Def not Microsoft. .NET Foundation and Contributors would be ok, if you wanted to pull out the main committers from history that might be a nice thing to do but not very future proof.

I have updated where the FWLinks point to that are used in the current codebase:

| ID | Original URL | New URL |
| --- | --- | --- |
| 261276 | http://msdn.microsoft.com/en-us/data/gg577609 | http://reactivex.io/ |
| 261274 | http://i.msdn.microsoft.com/en-us/data/gg577609.Logo(en-us,MSDN.10).png | http://i.msdn.microsoft.com/en-us/data/gg577609.Logo(en-us,MSDN.10).png |
| 261273 | http://rx.codeplex.com | https://github.com/Reactive-Extensions/Rx.NET |
| 261272 | http://msdn.microsoft.com/en-us/hh295787 | https://github.com/Reactive-Extensions/Rx.NET/blob/master/LICENSE |
| 201727 | http://social.msdn.microsoft.com/Forums/en-US/rx/threads | http://reactivex.io/community.html |
| 179929 | http://msdn.microsoft.com/en-us/data/gg577609 | http://reactivex.io/ |

Let me know if I missed any or we have a better location for them to go to.

We probably want to update http://reactivex.io/community.html at some point.

I've also updated http://rx.codeplex.com to point to GitHub and removed the issues, discussions and some other tabs to minimize the CodePlex footprint.

Sanity check turned up a NuGet regression #193

Can I add a request here related to builds, before this issue is closed. After a running _.\build.ps1_ I think the git repo should be still considered clean. Currently after running this build script (assuming this is what I am supposed to do), I end up with a dirty repo with 90 modified _AssemblyInfo.cs_ files.

Ideas on how to avoid this:

  • xcopy the code base to _working_ directory that is git ignored and execute the build from there. (as per how JSON.NET build works)
  • Have a linked AssemblyInfo.g.cs file that is git ignored
  • Use some build magic to set these values from the command line instead of in the file.
  • check in the most recent version of these files?

@LeeCampbell fixed in https://github.com/Reactive-Extensions/Rx.NET/commit/93d9f19f8e9aeb41ee63f076bd58383f0353dbb5. The tree should be clean after build now.

Thanks. Looks good now

Sorry just being picky. I get errors for the platforms I dont have installed i.e. WindowsPhoneApp,Version=v8.1, but I only noticed these errors if I go back and scroll through my builds. Should this be in a summary at the end of the build? Perhaps an enhancement for post June 27?

@LeeCampbell After the 27th would be better for sure. What errors were you getting though? It should be pulling the wpa81 references from our build feed, I didn't think you had to have anything installed for it?

Looking for sign-off here to tag https://github.com/Reactive-Extensions/Rx.NET/commit/327d7bdac1e2cbc2cb8751848f63480c84cdd8be as 3.0 from @bartdesmet @mattpodwysocki and @shiftkey. I believe we're now code-complete.

Looks good.

Good to go for me

Status update: have tagged the commit and have the unsigned binaries/packages. We ran into an issue with the tool used to repack the nupgks after singning. @martinwoodward is working on a workaround. Will have signed binaries posted shortly.

The final signed 3.0 binaries are on the MyGet feed and will be live on NuGet.org on the 27th.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tcberry picture tcberry  路  3Comments

jeremyVignelles picture jeremyVignelles  路  5Comments

weitzhandler picture weitzhandler  路  6Comments

davidnemeti picture davidnemeti  路  7Comments

weitzhandler picture weitzhandler  路  5Comments