What can You Learn from Menstruation and Symfony Releases

I wrote about monorepo and how it turned me into lazy programmer before.

As monorepo is use more and more, we should look at it again. Today from a bit atypical point of view: combined with bit of blood and sunshine.

Are you ready?

Disclaimer: this post has no intention to put menstruation into any bad light. Exactly the opposite - I admire women and love to learn from them.

Technical Natural Releases

We will look on release management. Non from traditional technical point of view that is already described in semantic versioning, Symfony BC Promise etc., but rather from view of nature.

Why? When I'm stuck with complicated architectural problem and can't figure it out, I take a break and go for a walk. Just observing world around me, absorbing inspiration without expectations - serendipity.

To be honest, many technologies we use originated from the nature. Processor and hard drives from brain, camera lenses from eyes and design pattern from pattern of nature. What else are falling leaves of tree in autumn? An event subscriber.

Menstruation Cycle as Inspiration

When we look at our main ability to survive - to reproduce ourselves, we see it's very easy to follow. Menstruation comes in cycles of ~28 days. All 4 parts of period have special meaning for the body of woman and her ability to get pregnant. We know when it happens, how long it takes and when it ends (roughly).

Now the interesting part: can you imagine software having release cycles in 28 days?

Just keep reading.

Four Seasons Cycle

A bit longer periodical system in nature that works for some time now. Again, each of 4 parts of this cycle has its meaning:

Every part takes 3 months and restarts every 12 month. You just know when winter comes.

Now back to the interesting part: could you imagine having release plan synced with the year period?


Also, did you know women that spend lot of time together tend to sync their menstruation cycle with each other? We will get back to the later software-wise.

What is Basic Stone for Evolution?

When we look at those patterns of nature, they have one important sign in common. A sign that we can see more and more in software development - predictability.

You know when the winter comes or when your spouse needs more attention and care when her period starts. You can plan, you can prepare and you can learn this by heart. As a result, you can focus on more dynamic things that are not to predictable - like your emotions, ideas or priorities on development of your project.

Symfony Cycle meets Nature Cycle

I first realized this at Fabien's talk about Symfony new release cycle on SymfonyCon Paris 2015:

So simple yet so amazing. I don't think about "when will the new Symfony come?" any more.

What about PHP?

I recall wondering when PHP 5.5, 5.6 or 7.0 will be out. No more thanks to yearly period beginning of December since PHP 7.0.

Menstruation Synchronization

As I wrote earlier, women that spend lot of time together tend to sync their menstruation cycle with each other. Have you noticed that Symfony matches PHP cycle every 2 years? Coincidence? I don't think so.

I think they're doing the right thing right.

Why We Should Menstruate Together?

We're getting back to software releases and monorepo. (If you see term monorepo first time, read this legendary post by danluu).

Some people say that big disadvantage of monorepo is that they have to tag their packages all together (like Symfony) even if nothing changed in any of them.

I see it as advantage, because that systematically leads to release cycle and open possibility to synchronization with other projects, like PHP + Symfony.

See for Yourself

Which of these 3 applications would you pick to maintain and upgrade based on their composer.json?


A with per-package versioning:

{
      "require": {
        "symfony/http-foundation": "3.3",
        "symfony/console": "3.1",
        "symfony/dependency-injection": "2.8",
        "symfony/event-dispatcher": "3.2",
        "doctrine/orm": "2.5",
        "doctrine/dbal": "2.3",
        "doctrine/annotations": "1.7",
        "nette/utils": "2.3",
        "nette/finder": "3.0"
      }
}

or B with per-vendor-sync

{
      "require": {
        "symfony/http-foundation": "3.3",
        "symfony/console": "3.3",
        "symfony/dependency-injection": "3.3",
        "symfony/event-dispatcher": "3.3",
        "doctrine/orm": "2.5",
        "doctrine/dbal": "2.5",
        "doctrine/annotations": "2.5",
        "nette/utils": "3.0",
        "nette/finder": "3.0"
      }
}

or C that looks like sci-fi:

{
      "require": {
        "symfony/http-foundation": "3.3",
        "symfony/console": "3.3",
        "symfony/dependency-injection": "3.3",
        "symfony/event-dispatcher": "3.3",
        "doctrine/orm": "3.3",
        "doctrine/dbal": "3.3",
        "doctrine/annotations": "3.3",
        "nette/utils": "3.3",
        "nette/finder": "3.3"
      }
}

Advantages of Synced Vendor - project B

Single version for every symfony/* package gives me so much freedom:

Disadvantage of Per Package Versioning - project A

And what if every package has it's own destiny?

Call Out to Package Maintainers

All this is not related just to Symfony, Doctrine, Nette or any other big PHP players like Zend, Laravel, CakePHP or Yii.

Every package, every dependency that has own versioning system means increased work PHP developers. That's stands if you agree with cycles or not. Version C being the easiest to upgrade and version A being the most difficult and also the most expensive.

Do you want to add extra work to developer's back to study your vendor release system?

Waiting for Tagging

On the other hand a package user, I bet you recall at least one package you longed to be tagged, but were frustrated not knowing when. It's quite common that first 3 versions are tagged in within 1 year, but then followed by 1+ year long pause.

Syncing with Symfony "menstruation" cycle

I like this synchronization, predictability, stability and maturation in our PHP ecosystem. That's why I'm trying to synchronize with Symfony release cycles. As from huge to small, as from seasons of year to menstruation, as from PHP to Symfony,

I bet you didn't notice, but with Symplify I try to release major version to minor of Symfony. Version 2.0 was released on July 6th 2017, right after Symfony 3.3 release in May.

Being predictable with BC breaks, support for older version and consistent with adding new version.

No Force, Just Inspiration

Do you maintain a package? What approach do you have on predictability of releases and why? Please, let me know in comments. I always love to hear new ideas.


Happy syncing!



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