Release a 1.x

[johnbland-wf]

Dart doesn't handle 0.x.x the same as 1.x.x. It makes updating consumers a chore when a lot of them target ^0.14.0 and this releases 0.15.x for a minor update.

Any chance we can get a 1.x to make consumption easier?

[zoechi]

What exactly is the issue with Dart/pub and pre 1.0.0 versions?
I'm pretty sure there is no difference except the ^ prefix in version constraints treats minor version increments in pre-1.0.0 like major version increments in post 1.0.0.

[johnbland-wf]

https://www.dartlang.org/tools/pub/dependencies#caret-syntax

Caret syntax provides a more compact way of expressing the most common sort of version constraint. ^version means “the range of all versions guaranteed to be backwards compatible with the specified version”, and follows pub’s convention for semantic versioning. For example, ^1.2.3 is equivalent to '>=1.2.3 <2.0.0', and ^0.1.2 is equivalent to '>=0.1.2 <0.2.0'. The following is an example of caret syntax...

Basically, if you're semver'ing this repo and provide a minor update (say 0.15.0), consumers using the caret will not get it. ^0.14.0 does not translate to 0.15.0. If this repo was on 1.0.0+, a consumer with ^1.14.0 would easily get 1.15.0 when that minor was released.

Right now, consumers have to either say < 1.0.0 or manually upgrade anything using the caret.

[zoechi]

That's what I tried to explain in my previous comment.
Non-breaking changes should get 0.14.1, breaking changes 0.15.0.
Breaking changes shouldn't be loaded automatically.

For versions above 1.0.0 non-breaking changes should become 1.1.0 and breaking changes 2.0.0.
^ follows this rule.

[frankpepermans]

We would only release a 0.15.x version when we do breaking changes. This repo has been in 0.14.x for quite a while now, a future update might for example focus on some renaming: flatMap to switchMap, amb to race etc...

Such an update would be 0.15.x, targetting ^0.14.0 is therefore safe :)

[johnbland-wf]

So the question remains, why not go 1.0 so minor is minor and not a major?

[zoechi]

Releasing 1.0.0 is usually a committment to try hard to avoid breaking changes. If there are already plans to make breaking changes there is no point in going 1.0.0.
Most Dart packages and many even from the Dart team are below 1.0.0.
Instead of spending time convincing maintainers to go 1.0.0, time would probably be better spent to embrace the situation.
^ already does most of the work for you.

[brianegan]

I actually think a 1.0.0 is a good call... However, I don't think we're quite ready yet!

Gameplan:

1. Figure out if we want to really rename this project or not. See Should we call this RxDart or something else? #95.
2. If we decide to rename, rename the operators we want to as well. If we decide not to, I think we should just keep operator names as they are today. They closely follow the Rx spec.
3. a) If we rename, give the changes a couple of months to "bake" before releasing a 1.0. b) No rename -- push a 1.0. The API has been stable for a while and is used in Production apps.
4. Release a 2.x once the new Version of Dart comes out, because it will introduce breaking changes to the core Stream apis.

Whatcha think?

[zoechi]

To bikeshed on the name. I'd remove dart from the name in any case.
Dart packages are usually searched in pub.dartlang.org and there Dart is implicit.
For others searching for "rx dart" would still find this package.

For operator names, I got the impression the names follow TypeScript Rx4, while many names changed in Rx5. TypeScript Rx is the only other Rx I know a bit about, therefore it's likely I miss a few things.

[johnbland-wf]

@brianegan I agree with the planning there. If it is a rename, that could be the 1.0. It would definitely break a lot to rename classes anyway.

[travissanderson-wf]

in a similar vein, it would be extremely useful if we could go back and add git tags at each release that is already on pub

[frankpepermans]

So we still haven't gone 1.0.0 :)

The naming issue is now a bigger problem one year later, since rxdart had gained in popularity thanks to Flutter/BLoC.

I'd say keep the rxdart name, it's actually consistent from the Rx perspective, they list all implementations as rx-language, i.e.

• rxjs
• rxgo
• rxjava
• ...

Regarding v1.0.0, I'd like to do a full code review first, maybe refactor a few tiny bits, but I think api-wise rxdart is complete enough for a first version.

[brianegan]

@frankpepermans I think you're right. I say let's give the current version of our BackPressureStreamTransformer a month or two to stabilize while we perform a final code review / any cleanup necessary.

[frankpepermans]

Sounds good!

[brianegan]

Hey all -- we're working on converting the current library over to Extension methods. Once that's in place and stabilized, we should be good to go on a version 1.0.

I'm going to close this out for now since I think the discussion has run it's course!

[blaugold]

Can this issue be reopened? RxDart is widely used in production, and the last breaking change was published 18 months ago. It does not seem like RxDart is still in an early phase where a 0.x version is typically used.