Why we Migrated from Nette to Symfony in 3 Weeks - Part 2 - Escaping Semantic Hell

Do you want to migrate your project from Nette to Symfony? In part 1 we showed you how to get your project ready, why it's important to make team commitment and what you can automate.

Today we'll look on one of the core reasons for this migration - escaping to semantic hell.

Semantic versioning aka semver tells you there is a BC break between nette/di in version 2.5 and 3.0. That's all you need to know as a web developer.

If you're an open-source developer, you'll probably learn more about semver. If you do it right, your user will be happy and never have to learn anything more 2.5 and 3.0.

From Nette...

When you run composer update Nette project, you'll find this normal:

You can see there 3 variants:

Today, there are also some Nette packages on 3, but some not. Who cares, right?

If you don't know Nette, you might think "why would somebody use the different versions in their composer.json"?

{
   "require": {
       "nette/utils": "^2.5",
       "nette/tokenizer": "^2.3",
       "nette/mail": "^2.4"
   }
}

Actually, composer.json looks like this:

{
   "require": {
       "nette/utils": "^2.3",
       "nette/tokenizer": "^2.3",
       "nette/mail": "^2.3"
   }
}

And that's a huge overhead with Nette versioning. Each package requires different versions, even v2, and 3 at the same time. If you upgrade to the newer version, the last thing you want to solve is conflicts in a package that are not yours:

What's different in Symfony?

When you install Symfony 4.0, you know that:

This approach is super stable since Symfony 3.4 and 2017. You can really on Symfony promise it more than of stability airplanes (I'm writing this post on one, I hope this statement is true :D).

Imagine you're looking for a bug across symfony/console 3.4, symfony/dependency-injection 4.1 and symfony/finder 4.2. Or just read the Symfony documentation in 3 different versions.

Don't Bother the User with Bad Package Design

Since I was raised in Nette, I used per-package tagging in my open-source projects (Zenify, Symnedi and now Symplify). It allowed me to release new versions when the package needed it.

That's nice to have for the maintainer. But what about the developers who use your packages? It's extra maintenance with 0-benefits.

There should be less and academic thinking in programming
and more pragmatic common sense. We were born with it.

Maintainers should read books like The Design of Everyday Things, Don't Make me Think and The Pragmatic Programmer to understand how others see our code.

Symfony KISS = Per-Vendor Tagging

So I decided to try per-vendor tagging over per-package tagging. Now I have to answer questions like "Why did you release a new version of your package, but no change between version 3.2.0 and 3.3.0?" But I know bothering developers with semver-hell is not a better choice, so I answer patiently (with a link to this post :)).

After all:

There are no best solutions, just trade-offs.

This was one of our reasons we switched from Nette to Symfony. Now we can upgrade all ~35 Symfony packages at once knowing they all work together.


Do you think it's impossible change for your project? Drop us a message at Rector. We'll help you.



Do you learn from my contents or use open-souce packages like Rector every day?
Consider supporting it on GitHub Sponsors. I'd really appreciate it!