Magento Architectural Discussions, 21 Aug 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Magento Architectural Discussion -- August, 21, 2019

Description

- Guidelines on exceptions in plugins and observers
- @api annotation in patch releases

Meeting notes: https://github.com/magento/architecture/issues/234

A

Girl, let's start from the topic so.

B

First, topic is about a dating exception section in in a technical guidelines. I added statement- plugins, must only saw exceptions declared was a method to which party miss added observers must only saw exceptions. The current body method, where that event, that triggers map, so we don't want plugins or observers, throw additional exceptions because client would not expect these exceptions.

A

A

A

The next one, okay.

B

So the next topic- I- don't really have anything to share for the next topic, but I want to discuss agent, annotation two classes and interfaces in the patch releases.

B

The issue of is identify annotation in the partial. Isn't that what there are two issues? One issue is.

B

Salmon exemption developer may find code max with API annotation in in particular for chilies, and he would assume that it's also available in the previous releases because, like he, would expect that it's it's okay to depend on the minor duration of the module components, things that class or interface.

B

But the issue is that zip code is not available in the previous realizes, so this can be misleading and another issue that I see is. If we had crossing interface marked with ap annotation, we need to bump for a major version and.

A

I'll measure that.

B

I'm sorry minor version minor version, yes, and if we do that, then our extensions are components that would depend on this component extension will have to change version of the dependency which we will create a lot of issues during the update, so considering said.

B

Considered in considering that this is new new, yet guy I mean on one hand this is a new guys, it's really risen and if we want people to use it, but because of these two issues, I would propose to market researcher annotation only it's a minor release, but mainly because of problems with these changing dependencies. If we want minor version.

A

Then I go back to changing dependencies. What is this so you described which issues we have one issues that somebody will start using this interface, but it doesn't exist in previous release. Yes,.

B

Yeah- and this is this issues like contradict each other a little bit so we can. We can say that this is a bad change, even though this is a my life change right.

A

B

It would be misleading and we've broken extensions, because our.

C

Current rules, it's minor.

D

C

So you cannot easily either partridges in any case. Yes,.

B

Yes, but some sometimes it's it's leaves so if, if it slips, then it will be, it can lead to broken extensions or and be made very confusing if we were minor version which, what should we do, according to our guidelines, Sam, everyone who depends on this modular component will have to change version of this dependency in order to be able to upgrade. If we add something in the framework, then it's pretty big problem, because a lot of extensions depend on framework also, if it's like some of the most important core components like catalog or customer.

B

Also, there is a big chance that well, it's almost guaranteed that zero would be an extension that depends on catalog, customer or framework.

A

B

It actually, from my point of view, creates a a big problem if we bump a minor version, when we add this API annotation.

C

B

C

Same for any minor changes, what's specific about experimentation, she's.

A

Saying that people are adding a per annotation right now or it's not clear.

B

There was a discussion, I think I, think I was discussing this receiver and he suggested that we it's better to add API annotation. But the discussion is this and vinay that we had I thought that it would be better to reconsider it and.

B

Maybe, if we're, if we want to do this and conduct analysis.

A

B

Approach as I approach is.

A

General, yes, okay, so.

B

The only disadvantage is that something that is actually API cuz we can become the wizard I. We will say that this is API only in the next minor release.

D

Potential problem is, we usually create such guys if teams need to depend from.

A

Another module itself.

D

A module visa need to depend on some functionality of module, a which they want to Marcus a guy who, and what happens? You know we agree, usually that we do not market. We add this API interface, we don't market which we can still depend from what will be on this interface.

D

A

One drawback is that people won't be able to use it as public API or they will have to use it as private code. One more drawback for me right now, though I think it's solvable is that I don't think we have any task follow-up tasks usually to market with API.

C

Concern that they don't tracking.

A

But it can be solvable.

A

We still can avoid adding at the API invite release, but we just need to have some track of what needs to be marked in next might not release, and we need to have a task in backward for that. From my experience, teams use related tasks for hearing okay. It's.

D

For the changes which I was was.

A

It ever executed this tasks.

D

A

C

I believe, if this be I classes, it's my job change.

C

Interface, that someone need to implement to extensionality.

A

C

If you add this interface at zero, not any of different paths to use this functionality, except in inferences interface, that's like major change.

C

A

C

Replace current functionalities news by its major because you broke all parent, were here: I.

A

Would even replace so if you remove an interface and add another one. Instead,.

C

Or you just want some functionality that you can introduce without for in some different way, for example, is heaven.

A

Tation, meaning that's okay, we created a new interface, for example, so this is not major. This is minor, yeah, okay, so I guess just should be clarified for everyone. Maybe you can I, don't know, should be somehow communicated to the team. So it's clear for everyone maybe run just some email or message and.

D

A

Just to be clear on that, okay, yeah so I will I will skip my topic. We can discuss it next time. It's about Mexico, eight issues, it's not very urgent right now and they want Anton copier to be here for the discussion. I think he's not here right. Yes, anything else that you wanted to discuss today. I.

C

Have some mostly related topics, but if.

C

A

Not urgent, it would be good. You.

C

A

Move it to next time when we all haven't on here.

A

Okay, then, for that sold, we are done for today and I'll, send I'll write down some morning notes and we'll send it. Everyone thanks for coming, see you next time.