Should we change something to limit the amount of breaking Changes on v19?

[Flyingmana]

Over the last months we had several breaking changes merged into v19.
Some of them are bigger, some of them are smaller.

examples(I will extend this list continuously):

• Fix xml validation problems #2242
• Sync v19 v20 #2810

[tmotyl]

We should change the process to work mainly on v20, and only cherry-pick important bug fixes and security changes to v19.

[fballiano]

@tmotyl please vote for OpenMage/rfcs#6

[tmotyl]

Not sure what do you mean

[fballiano]

why is #2810 considered BC?

[sreichel]

Think @Flyingmana means changed translateable string. This can be exlcuded an reverted in v20.

[fballiano]

we need an RFC to decide once and for all how to handle changes in the translatable strings, although we already broke all of the translation packs multiple times so...

but still, it's a bit of a stretch to consider that a BC, it technically is but then half of the merged PRs are BC :-D

[sreichel]

I'd ask another question ...

Should we change something to limit the amount of breaking Changes on v20?

I think we only have 3-4 real BC breaking PRs (IE8, ...). Others could be written w/o breaking anything. It was no fun to spent time for #2854.

#2810 should be only a small PR to remove some diffs between branches and now causes trouble. (comments/deprecation notes also belong to v19. Change to that translatable should not had be added at all. Minor changes (to v20 only) that make things more complicate.

#1257 seems to be more fix, rather a bc break

In rare cases we can use Mage::getOpenMageMajorVersion() === 20 to sperate code/functionality.

Last one ... IE support. I think we dont break the "LTS backward compatibility promise" when we remove that. Its 2023.

[sreichel]

And ... we have some PRs that brings no benefits, but have potential to break something. E.g.

• Removed "admin routing compatibility mode" for extensions #1551
• Removed unused autoloaders Mage_Autoload_Simple and Magento\Autoload\Simple #2859

We can mark every method/class as deprecated, but keep it for now.

It does not hurt and does not break anything.

[fballiano]

I think they have the benefit of cleaning the code for developers that are studying it to use it and they can get confused by the amount of dead files and code.
It should also make the tests (phpstan etc) run on less useless code sparing time and resources.

The right way would be deprecating it (but then it never gets removed) or removing it from v20 (but we have the whole other topic there).

But it's good because it's sparks the conversation ;-)

[sreichel]

You know i agree with removing dead code, but we're just talking about a few files here,

I dont know if the other autoloaders are used in extensions. (Also dont know any extensions that did). Removing admin routing can break old extensions that still work.

The right way would be deprecating it (but then it never gets removed) or removing it from v20

I'd not even remove them from v20 ... this should be done in next major release.