Build against Rx Official 1.0 - not 1.1 experimental

[reactiveui]

Build against Rx Official 1.0 - not 1.1 experimental

[anaisbetts]

Are you concerned about reliability? The difference between
Experimental and Stable is the API contract, not quality - i.e. the
thing being experimented on is the shape of future methods /
operators. I can assure you, that the Experimental version is just as
high-quality as the Stable version.

otherwise I've got a big assembly versioning problem on my hands.

Git makes maintaining your own branch and keeping it up-to-date
really easy, so if you don't believe me, you can always live on 1.0
:)

I realize this isn't optimal, but the build and release process for
RxUI is already really complex and messy because we support 4
architectures, and VS loves to mess with the Rx version #s in the
csproj file and break stuff. Maintaining both a 1.0 and 1.1 branch
(and making sure they both work!) would be bad for my sanity :)

Paul Betts [email protected]

On Fri, Jul 22, 2011 at 12:04 PM, Iristyle
[email protected]
wrote:

We're already using Rx in other projects, but the 1.0 official and not 1.1 experimental, which we don't want to take a dependency on.

I grabbed your source and rebuilt -- doesn't look like you're using anything from 1.1.  I would like to see official releases based off of 1.0, otherwise I've got a big assembly versioning problem on my hands.

Thanks for the consideration.

Reply to this email directly or view it on GitHub:
https://github.com/xpaulbettsx/ReactiveUI/issues/22

[Iristyle]

Reliability, no... API churn, yes.

We have a number of projects here, where the binaries are shared in a few common subrepos (using hg internally) to kind of standardize everything in a very build-server friendly kind of way (Jenkins).

I'm trying to keep down the size of our shared /lib folders since we're using DVCS and I'm trying to make sure managing our dependencies doesn't get out of control by only picking up new binaries for our common toolset as they hit major milestones / have things we need (xunit / autofixture / fakeiteasy / autofac / automapper / fluentvalidation / restsharp / servicestack / rx / nlog / caliburn micro / reactiveui ... etc). Since you use Git, you know that growing your repo over time can be a problem, so I try to do it carefully ;0

Since the experimental version has a ways to go before finalizing, and we currently don't need anything in it, I'd rather hold off on stuffing temporary binaries into the tree until we need to.

[Iristyle]

So I just did a quick check to see if NuGet has gotten close enough to Maven in terms of allowing package manifests to be committed, then the binaries brought down as needed, without storing them in source control.

That has basically been the biggest deal breaker for me, given the care we take in managing dependencies + repository sizes.

As it turns out, I didn't realize that they had addressed that problem:
http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html

So I may have a better way to address my root problem.