Skip to content

Commit b1192f1

Browse files
authored
grammar (#45355)
1 parent 37e086b commit b1192f1

File tree

1 file changed

+9
-7
lines changed

1 file changed

+9
-7
lines changed

docs/orleans/grains/grain-versioning/backward-compatibility-guidelines.md

Lines changed: 9 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@ Writing backward compatible code can be hard and difficult to test. This article
1010

1111
## Never change the signature of existing methods
1212

13-
Because of the way on how Orleans serializer work, you should never change the signature
13+
Because of how the Orleans serializer works, you should never change the signature
1414
of existing methods.
1515

1616
The following example is correct:
@@ -57,7 +57,9 @@ public interface IMyGrain : IGrainWithIntegerKey
5757
```
5858

5959
> [!IMPORTANT]
60-
> You should not do this change in your code, as it's an example of a bad practice that leads to very bad side-effects. This is an example of what can happen if you just rename the parameter names: let's say that we have the two following interface version deployed in the cluster:
60+
> Do NOT make this change in your code, as it's an example of a bad practice that leads to very bad side effects.
61+
62+
This is an example of what can happen if you just rename the parameter names. Assume you have the following two interface versions deployed in the cluster:
6163

6264
```csharp
6365
[Version(1)]
@@ -72,12 +74,12 @@ public interface IMyGrain : IGrainWithIntegerKey
7274
[Version(2)]
7375
public interface IMyGrain : IGrainWithIntegerKey
7476
{
75-
// return a - b
77+
// return b - a
7678
Task<int> Subtract(int b, int a);
7779
}
7880
```
7981

80-
This methods seems identical. But if the client was called with V1, and the request is
82+
These methods seem identical. But if the client was called with V1, and the request is
8183
handled by a V2 activation:
8284

8385
```csharp
@@ -89,7 +91,7 @@ This is due to how the internal Orleans serializer works.
8991

9092
## Avoid changing existing method logic
9193

92-
It can seems obvious, but you should be very careful when changing the body of an existing method.
94+
It can seem obvious, but you should be very careful when changing the body of an existing method.
9395
Unless you are fixing a bug, it is better to just add a new method if you need to modify the code.
9496

9597
Example:
@@ -128,7 +130,7 @@ public interface MyGrain : IMyGrain
128130

129131
## Do not remove methods from grain interfaces
130132

131-
Unless you are sure that they are no longer used, you should not remove methods from the grain interface.
133+
Unless you are sure that they're no longer used, you should not remove methods from the grain interface.
132134
If you want to remove methods, this should be done in 2 steps:
133135

134136
1. Deploy V2 grains, with V1 method marked as `Obsolete`
@@ -155,7 +157,7 @@ If you want to remove methods, this should be done in 2 steps:
155157
}
156158
```
157159

158-
2. When you are sure that no V1 calls are made (effectively V1 is no longer deployed in the running cluster), deploy V3 with V1 method removed
160+
2. When you are sure that no V1 calls are made (effectively V1 is no longer deployed in the running cluster), deploy V3 with V1 method removed.
159161

160162
```csharp
161163
[Version(3)]

0 commit comments

Comments
 (0)