Labeling breaking changes

[John Clingan]

I began to update the release tracking issue in order to make it easier to identify breaking changes for spec implementors and for end-user developers, and I noticed two things:

1) Some specs do not label breaking changes. Those are identified in the link above by specs not having an "incompatible change" text listed.

2) For those specs that do have labels, there is no consistency ("api-breaking", "incompatible change", "backward incompatible changes", "breaking change")

First, it would be nice to use a consistent label. Not a fixed requirement, but a nice-to-have. Worth a (hopefully short) discussion here.

Second, for those who do not label breaking changes, can you please create a label and label them? It makes it much easier to track the impact of a major platform release. Please create a label even if your spec does not foresee a breaking change this release.

Thanks!

The management :-)

[Jérémie Bresson]

Hi John,

The MP-OpenAPI project is working on a 2.0 release containing some breaking changes.

We were asked by Emily-Jiang to list them via issue #441:

https://github.com/eclipse/microprofile-open-api/issues/441

When we did those breaking changes, we tracked them with #251:

https://github.com/eclipse/microprofile-open-api/issues/251

I understand that the issue #251 can't be good enough for a specification, but I do not know how to move forward and I would appreciate some guidance about the requested formalism.

Thank you a lot.

[Jérémie Bresson]

Hi John,

Sorry if I expanded your thread a little bit by asking for more guidance about the way to go with "breaking changes".

This is really something that is not clear to me now.

I have created the requested label "api-breaking" in the MP-OpenAPI project:

https://github.com/eclipse/microprofile-open-api/labels/api-breaking

Feel free to change the name, if something else is decided.

Right now I have tagged only issues mentioned in #251:

https://github.com/eclipse/microprofile-open-api/issues/251

I was wondering if I should add the label to closed PRs as well…

I hope it helps you and I hope the breaking change topic will be improved with more clearer guide lines.

[Werner Keil]

Hi,

Since neither of MP is currently used in a platform like Jakarta EE, guess that's between the Open API team and any products that may use it, if those changes are problematic to its users or not.

If either spec would ever be able to join the platform after the WG effort and adoption of the EFSP, then it would of course be different and backward compatibility had to be looked at more carefully.

[Emily Jiang]

Hi John,

It is good to label the issues with various labels as mentioned by John so that when you add Breaking Change subsection under your release note, you can easily fish them out and document accurately for end users.

Thanks

Emily

[John Clingan]

Whups, I missed this. Thanks, Jeremie, for adding the label. I don't think we need to go back and add the label to past releases. Let's move forward with the label and see how it goes.

[Emily Jiang]

I thought this further after yesterday's MP call, I think the label we push forward should be "backward incompatible changes" as these changes might not related to any APIs, so "API-Breaking" may not be a right label for covering all kinds of backward incompatible changes. Thoughts?

Emily

[Ladislav Thon]

st 22. 7. 2020 v 17:04 odesílatel 'Emily Jiang' via MicroProfile <microp...@googlegroups.com> napsal:

"backward incompatible changes"

"breaking changes" is a synonym (to me?), and it's shorter.

LT

 

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/74b38626-f098-443a-8abc-41c5ad8d2efdo%40googlegroups.com.

[Emily Jiang]

ok, LT! "breaking changes" is fine with me :).

Thanks

Emily

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[John Clingan]

Works for me.

[Emily Jiang]

Okay, I have updated the wiki on the requirement on Release Note, which includes a section on Incompatible Changes.

Next action:

1. Every spec will need to create a labe 'Incompatible Changes'.
2. Label the issues that introduce such changes. See here for an example.
   
3. Clearly document Incompatible Changes in the Release Notes for the upcoming major release by following the above instruction.
   

Thanks

Emily