How is changing a field to readonly a breaking change
I have a class library Foo, currently in version 1.0.0.
Another library Foo.Extensions of version 1.0.0, has Foo 1.0.0 as a dependency.
Both libraries try to adhere to semantic versioning, i.e. a program using Foo.Extensions 1.0.0, should be upgrade Foo to version 1.0.1 without breaking functionality of Foo.Extensions.
To avoid any breakage, I'm concerned about making updates to Foo in a source and binary compatibility way.
The Breaking Change Rules states that
Adding
readonlyto a field
is disallowed.
When is this a breaking change for e.g.
public class Foo
{
private int bar;
}
My best guess would be in some sort of reflection scenario, as I've experienced some (de)serializers to require properties to at least have a private setter.
How does this relates to removing a private setter from a property?
public class Foo2
{
public int Bar2 { get; private set; }
}
c#
asked Nov 22 '18 at 21:43
Jonas NyrupJonas Nyrup
560310
|
show 1 more comment
I have a class library Foo, currently in version 1.0.0.
Another library Foo.Extensions of version 1.0.0, has Foo 1.0.0 as a dependency.
Both libraries try to adhere to semantic versioning, i.e. a program using Foo.Extensions 1.0.0, should be upgrade Foo to version 1.0.1 without breaking functionality of Foo.Extensions.
To avoid any breakage, I'm concerned about making updates to Foo in a source and binary compatibility way.
The Breaking Change Rules states that
Adding
readonlyto a field
is disallowed.
When is this a breaking change for e.g.
public class Foo
{
private int bar;
}
My best guess would be in some sort of reflection scenario, as I've experienced some (de)serializers to require properties to at least have a private setter.
How does this relates to removing a private setter from a property?
public class Foo2
{
public int Bar2 { get; private set; }
}
c#
asked Nov 22 '18 at 21:43
Jonas NyrupJonas Nyrup
560310
2
If you made that change, what do you think it might break? Keep in mind the doc you liked to is for a framework - so they are concerned with ensuring that API changes don't break the callers to the API.
– mjwills
Nov 22 '18 at 21:51
Adding to the previous comment, your example isnt the greatest, considering thatbarisnt part of the public API of your example class.
– Jota.Toledo
Nov 22 '18 at 22:11
1
Also, given the quote you linked to was in the context of signatures (i.e. method signatures) you may consider updating the question to show an actual method signature. I also strongly suspect that the context implies that the field is notprivate(since otherwise it wouldn't form part of the signature).
– mjwills
Nov 22 '18 at 22:31
If there's anIncrementBar()method in the Foo class that incrementsbar, that will not work anymore; ergo, Breaking Change.
– Yatin
Nov 22 '18 at 23:05
1
@mjwills, I agree, and even I couldn't think of another scenario where this change would be a breaking change.
– Yatin
Nov 23 '18 at 0:44
|
show 1 more comment
I have a class library Foo, currently in version 1.0.0.
Another library Foo.Extensions of version 1.0.0, has Foo 1.0.0 as a dependency.
Both libraries try to adhere to semantic versioning, i.e. a program using Foo.Extensions 1.0.0, should be upgrade Foo to version 1.0.1 without breaking functionality of Foo.Extensions.
To avoid any breakage, I'm concerned about making updates to Foo in a source and binary compatibility way.
The Breaking Change Rules states that
Adding
readonlyto a field
is disallowed.
When is this a breaking change for e.g.
public class Foo
{
private int bar;
}
My best guess would be in some sort of reflection scenario, as I've experienced some (de)serializers to require properties to at least have a private setter.
How does this relates to removing a private setter from a property?
public class Foo2
{
public int Bar2 { get; private set; }
}
c#
asked Nov 22 '18 at 21:43
Jonas NyrupJonas Nyrup
560310
I have a class library Foo, currently in version 1.0.0.
Another library Foo.Extensions of version 1.0.0, has Foo 1.0.0 as a dependency.
Both libraries try to adhere to semantic versioning, i.e. a program using Foo.Extensions 1.0.0, should be upgrade Foo to version 1.0.1 without breaking functionality of Foo.Extensions.
To avoid any breakage, I'm concerned about making updates to Foo in a source and binary compatibility way.
The Breaking Change Rules states that
Adding
readonlyto a field
is disallowed.
When is this a breaking change for e.g.
public class Foo
{
private int bar;
}
My best guess would be in some sort of reflection scenario, as I've experienced some (de)serializers to require properties to at least have a private setter.
How does this relates to removing a private setter from a property?
public class Foo2
{
public int Bar2 { get; private set; }
}
c#
c#
asked Nov 22 '18 at 21:43
Jonas NyrupJonas Nyrup
560310
asked Nov 22 '18 at 21:43
Jonas NyrupJonas Nyrup
560310
edited Nov 23 '18 at 7:37
Jonas Nyrup
asked Nov 22 '18 at 21:43
Jonas NyrupJonas Nyrup
560310
asked Nov 22 '18 at 21:43
Jonas NyrupJonas Nyrup
560310
asked Nov 22 '18 at 21:43
Jonas NyrupJonas Nyrup
560310
560310
2
If you made that change, what do you think it might break? Keep in mind the doc you liked to is for a framework - so they are concerned with ensuring that API changes don't break the callers to the API.
– mjwills
Nov 22 '18 at 21:51
Adding to the previous comment, your example isnt the greatest, considering thatbarisnt part of the public API of your example class.
– Jota.Toledo
Nov 22 '18 at 22:11
1
Also, given the quote you linked to was in the context of signatures (i.e. method signatures) you may consider updating the question to show an actual method signature. I also strongly suspect that the context implies that the field is notprivate(since otherwise it wouldn't form part of the signature).
– mjwills
Nov 22 '18 at 22:31
If there's anIncrementBar()method in the Foo class that incrementsbar, that will not work anymore; ergo, Breaking Change.
– Yatin
Nov 22 '18 at 23:05
1
@mjwills, I agree, and even I couldn't think of another scenario where this change would be a breaking change.
– Yatin
Nov 23 '18 at 0:44
|
show 1 more comment
2
If you made that change, what do you think it might break? Keep in mind the doc you liked to is for a framework - so they are concerned with ensuring that API changes don't break the callers to the API.
– mjwills
Nov 22 '18 at 21:51
Adding to the previous comment, your example isnt the greatest, considering thatbarisnt part of the public API of your example class.
– Jota.Toledo
Nov 22 '18 at 22:11
1
Also, given the quote you linked to was in the context of signatures (i.e. method signatures) you may consider updating the question to show an actual method signature. I also strongly suspect that the context implies that the field is notprivate(since otherwise it wouldn't form part of the signature).
– mjwills
Nov 22 '18 at 22:31
If there's anIncrementBar()method in the Foo class that incrementsbar, that will not work anymore; ergo, Breaking Change.
– Yatin
Nov 22 '18 at 23:05
1
@mjwills, I agree, and even I couldn't think of another scenario where this change would be a breaking change.
– Yatin
Nov 23 '18 at 0:44
2
2
If you made that change, what do you think it might break? Keep in mind the doc you liked to is for a framework - so they are concerned with ensuring that API changes don't break the callers to the API.
– mjwills
Nov 22 '18 at 21:51
If you made that change, what do you think it might break? Keep in mind the doc you liked to is for a framework - so they are concerned with ensuring that API changes don't break the callers to the API.
– mjwills
Nov 22 '18 at 21:51
Adding to the previous comment, your example isnt the greatest, considering that
bar isnt part of the public API of your example class.– Jota.Toledo
Nov 22 '18 at 22:11
Adding to the previous comment, your example isnt the greatest, considering that
bar isnt part of the public API of your example class.– Jota.Toledo
Nov 22 '18 at 22:11
1
1
Also, given the quote you linked to was in the context of signatures (i.e. method signatures) you may consider updating the question to show an actual method signature. I also strongly suspect that the context implies that the field is not
private (since otherwise it wouldn't form part of the signature).– mjwills
Nov 22 '18 at 22:31
Also, given the quote you linked to was in the context of signatures (i.e. method signatures) you may consider updating the question to show an actual method signature. I also strongly suspect that the context implies that the field is not
private (since otherwise it wouldn't form part of the signature).– mjwills
Nov 22 '18 at 22:31
If there's an
IncrementBar() method in the Foo class that increments bar, that will not work anymore; ergo, Breaking Change.– Yatin
Nov 22 '18 at 23:05
If there's an
IncrementBar() method in the Foo class that increments bar, that will not work anymore; ergo, Breaking Change.– Yatin
Nov 22 '18 at 23:05
1
1
@mjwills, I agree, and even I couldn't think of another scenario where this change would be a breaking change.
– Yatin
Nov 23 '18 at 0:44
@mjwills, I agree, and even I couldn't think of another scenario where this change would be a breaking change.
– Yatin
Nov 23 '18 at 0:44
|
show 1 more comment
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53438291%2fhow-is-changing-a-field-to-readonly-a-breaking-change%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53438291%2fhow-is-changing-a-field-to-readonly-a-breaking-change%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
If you made that change, what do you think it might break? Keep in mind the doc you liked to is for a framework - so they are concerned with ensuring that API changes don't break the callers to the API.
– mjwills
Nov 22 '18 at 21:51
Adding to the previous comment, your example isnt the greatest, considering that
barisnt part of the public API of your example class.– Jota.Toledo
Nov 22 '18 at 22:11
1
Also, given the quote you linked to was in the context of signatures (i.e. method signatures) you may consider updating the question to show an actual method signature. I also strongly suspect that the context implies that the field is not
private(since otherwise it wouldn't form part of the signature).– mjwills
Nov 22 '18 at 22:31
If there's an
IncrementBar()method in the Foo class that incrementsbar, that will not work anymore; ergo, Breaking Change.– Yatin
Nov 22 '18 at 23:05
1
@mjwills, I agree, and even I couldn't think of another scenario where this change would be a breaking change.
– Yatin
Nov 23 '18 at 0:44