Skip to content

Commit 17cb353

Browse files
viktorklangviktorklang
committed
WIP of release notes
1 parent c3b2c6d commit 17cb353

File tree

1 file changed

+166
-1
lines changed

1 file changed

+166
-1
lines changed

‎RELEASE-NOTES.md

+166-1
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,168 @@
11
# Release notes for Reactive Streams
22

3-
Changes will be listed below after version 1.0.0 is released.
3+
---
4+
5+
# Version 1.0.1 released on YYYY-MM-DD
6+
7+
## Announcement:
8+
9+
After more than two years since 1.0.0, we are proud to announce the immediate availability of `Reactive Streams version 1.0.1-RC1`.
10+
11+
Since 1.0.0 was released `Reactive Streams` has managed to achieve most, if not all, it set out to achieve. There are now numerous implementations, and it is scheduled to be included in [JDK9](http://download.java.net/java/jdk9/docs/api/java/util/concurrent/Flow.html).
12+
13+
Also, most importantly, there are no semantical incompatibilities included in this release.
14+
15+
When JDK9 ships, `Reactive Streams` will publish a compatibility/conversion library to seamlessly convert between the `java.util.concurrent.Flow` and the `org.reactivestreams` namespaces.
16+
17+
## Highlights:
18+
19+
- Specification
20+
+ A new [Glossary](https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.1-RC1/README.md#glossary) section
21+
+ Description of the intent behind every single rule
22+
+ No breaking semantical changes
23+
+ Multiple rule [clarifications](#specification-clarifications)
24+
- Interfaces
25+
+ No changes
26+
+ Improved JavaDoc
27+
- Technology Compatibility Kit (TCK)
28+
+ Improved coverage
29+
+ Improved JavaDoc
30+
+ Multiple test [alterations](#tck-alterations)
31+
32+
## Specification clarifications
33+
34+
## Publisher Rule 1
35+
36+
**1.0.0:** The total number of onNext signals sent by a Publisher to a Subscriber MUST be less than or equal to the total number of elements requested by that Subscriber´s Subscription at all times.
37+
38+
**1.0.1:** The total number of onNext´s signalled by a Publisher to a Subscriber MUST be less than or equal to the total number of elements requested by that Subscriber´s Subscription at all times.
39+
40+
**Comment: Minor spelling update.**
41+
42+
## Publisher Rule 2
43+
44+
**1.0.0:** A Publisher MAY signal less onNext than requested and terminate the Subscription by calling onComplete or onError.
45+
46+
**1.0.1:** A Publisher MAY signal fewer onNext than requested and terminate the Subscription by calling onComplete or onError.
47+
48+
**Comment: Minor spelling update.**
49+
50+
## Publisher Rule 3
51+
52+
**1.0.0:** onSubscribe, onNext, onError and onComplete signaled to a Subscriber MUST be signaled sequentially (no concurrent notifications).
53+
54+
**1.0.1:** onSubscribe, onNext, onError and onComplete signaled to a Subscriber MUST be signaled in a thread-safe manner—and if performed by multiple threads—use external synchronization.
55+
56+
**Comment: Reworded the part about sequential signal and its implications, for clarity.**
57+
58+
## Subscriber Rule 6
59+
60+
**1.0.0:** A Subscriber MUST call Subscription.cancel() if it is no longer valid to the Publisher without the Publisher having signaled onError or onComplete.
61+
62+
**1.0.1:** A Subscriber MUST call Subscription.cancel() if the Subscription is no longer needed.
63+
64+
**Comment: Rule could be reworded since it now has an intent section describing desired effect.**
65+
66+
## Subscriber Rule 11
67+
68+
**1.0.0:** A Subscriber MUST make sure that all calls on its onXXX methods happen-before [1] the processing of the respective signals. I.e. the Subscriber must take care of properly publishing the signal to its processing logic.
69+
70+
**1.0.1:** A Subscriber MUST make sure that all calls on its signal methods happen-before the processing of the respective signals. I.e. the Subscriber must take care of properly publishing the signal to its processing logic.
71+
72+
**Comment: Rule slightly reworded to use the glossary for `signal` instead of the more *ad-hoc* name "onXXX methods". Footnote was reworked into the Intent-section of the rule.**
73+
74+
## Subscription Rule 1
75+
76+
**1.0.0:** Subscription.request and Subscription.cancel MUST only be called inside of its Subscriber context. A Subscription represents the unique relationship between a Subscriber and a Publisher [see 2.12].
77+
78+
**1.0.1:** Subscription.request and Subscription.cancel MUST only be called inside of its Subscriber context.
79+
80+
**Comment: Second part of rule moved into the Intent-section of the rule.**
81+
82+
## Subscription Rule 3
83+
84+
**1.0.0:** Subscription.request MUST place an upper bound on possible synchronous recursion between Publisher and Subscriber[1].
85+
86+
**1.0.1:** Subscription.request MUST place an upper bound on possible synchronous recursion between Publisher and Subscriber.
87+
88+
**Comment: Footnote reworked into the Intent-section of the rule.**
89+
90+
## Subscription Rule 4
91+
92+
**1.0.0:** Subscription.request SHOULD respect the responsivity of its caller by returning in a timely manner[2].
93+
94+
**1.0.1:** Subscription.request SHOULD respect the responsivity of its caller by returning in a timely manner.
95+
96+
**Comment: Footnote reworked into the Intent-section of the rule.**
97+
98+
## Subscription Rule 5
99+
100+
**1.0.0:** Subscription.cancel MUST respect the responsivity of its caller by returning in a timely manner[2], MUST be idempotent and MUST be thread-safe.
101+
102+
**1.0.1:** Subscription.cancel MUST respect the responsivity of its caller by returning in a timely manner, MUST be idempotent and MUST be thread-safe.
103+
104+
**Comment: Footnote reworked into the Intent-section of the rule.**
105+
106+
## Subscription Rule 13
107+
108+
**1.0.0:** While the Subscription is not cancelled, Subscription.cancel() MUST request the Publisher to eventually drop any references to the corresponding subscriber. Re-subscribing with the same Subscriber object is discouraged [see 2.12], but this specification does not mandate that it is disallowed since that would mean having to store previously cancelled subscriptions indefinitely.
109+
110+
**1.0.1:** While the Subscription is not cancelled, Subscription.cancel() MUST request the Publisher to eventually drop any references to the corresponding subscriber.
111+
112+
**Comment: Second part of rule reworked into the Intent-section of the rule.**
113+
114+
## Subscription Rule 15
115+
116+
**1.0.0:** Calling Subscription.cancel MUST return normally. The only legal way to signal failure to a Subscriber is via the onError method.
117+
118+
**1.0.1:** Calling Subscription.cancel MUST return normally.
119+
120+
**Comment: Replaced second part of rule with a definition for `return normally` in the glossary.**
121+
122+
## Subscription Rule 16
123+
124+
**1.0.0:** Calling Subscription.request MUST return normally. The only legal way to signal failure to a Subscriber is via the onError method.
125+
126+
**1.0.1:** Calling Subscription.request MUST return normally.
127+
128+
**Comment: Replaced second part of rule with a definition for `return normally` in the glossary.**
129+
130+
## Subscription Rule 17
131+
132+
**1.0.0:** A Subscription MUST support an unbounded number of calls to request and MUST support a demand (sum requested - sum delivered) up to 2^63-1 (java.lang.Long.MAX_VALUE). A demand equal or greater than 2^63-1 (java.lang.Long.MAX_VALUE) MAY be considered by the Publisher as “effectively unbounded”[3].
133+
134+
**1.0.1:** A Subscription MUST support an unbounded number of calls to request and MUST support a demand up to 2^63-1 (java.lang.Long.MAX_VALUE). A demand equal or greater than 2^63-1 (java.lang.Long.MAX_VALUE) MAY be considered by the Publisher as “effectively unbounded”.
135+
136+
**Comment: Rule simplified by defining `demand` in the glossary, and footnote was reworked into the Intent-section of the rule.**
137+
138+
---
139+
140+
## TCK alterations
141+
142+
- Fixed potential resource leaks in partially consuming Publisher tests ([#375](https://github.com/reactive-streams/reactive-streams-jvm/issues/375))
143+
- Fixed potential resource leaks in partially emitting Subscriber tests ([#372](https://github.com/reactive-streams/reactive-streams-jvm/issues/372), [#373](https://github.com/reactive-streams/reactive-streams-jvm/issues/373))
144+
- Renamed `untested_spec305_cancelMustNotSynchronouslyPerformHeavyCompuatation` to `untested_spec305_cancelMustNotSynchronouslyPerformHeavyComputation` ([#306](https://github.com/reactive-streams/reactive-streams-jvm/issues/306))
145+
- Allow configuring separate timeout for "no events during N time", allowing for more aggressive timeouts in the rest of the test suite if required ([#314](https://github.com/reactive-streams/reactive-streams-jvm/issues/314))
146+
- New test verifying Rule 2.10, in which subscriber must be prepared to receive onError signal without having signaled request before ([#374](https://github.com/reactive-streams/reactive-streams-jvm/issues/374))
147+
---
148+
149+
## Contributors
150+
+ Roland Kuhn [(@rkuhn)](https://github.com/rkuhn)
151+
+ Ben Christensen [(@benjchristensen)](https://github.com/benjchristensen)
152+
+ Viktor Klang [(@viktorklang)](https://github.com/viktorklang)
153+
+ Stephane Maldini [(@smaldini)](https://github.com/smaldini)
154+
+ Stanislav Savulchik [(@savulchik)](https://github.com/savulchik)
155+
+ Konrad Malawski [(@ktoso)](https://github.com/ktoso)
156+
+ Slim Ouertani [(@ouertani)](https://github.com/ouertani)
157+
+ Martynas Mickevičius [(@2m)](https://github.com/2m)
158+
+ Luke Daley [(@ldaley)](https://github.com/ldaley)
159+
+ Colin Godsey [(@colinrgodsey)](https://github.com/colinrgodsey)
160+
+ David Moten [(@davidmoten)](https://github.com/davidmoten)
161+
+ (new) Brian Topping [(@briantopping)](https://github.com/briantopping)
162+
+ (new) Rossen Stoyanchev [(@rstoyanchev)](https://github.com/rstoyanchev)
163+
+ (new) Björn Hamels [(@BjornHamels)](https://github.com/BjornHamels)
164+
+ (new) Jake Wharton [(@JakeWharton)](https://github.com/JakeWharton)
165+
+ (new) Anthony Vanelverdinghe[(@anthonyvdotbe)](https://github.com/anthonyvdotbe)
166+
+ (new) Kazuhiro Sera [(@seratch)](https://github.com/seratch)
167+
+ (new) Dávid Karnok [(@akarnokd)](https://github.com/akarnokd)
168+
+ (new) Evgeniy Getman [(@egetman)](https://github.com/egetman)

0 commit comments

Comments
 (0)