Semantic Versioning and Naming

Yii 3.0 Design discussions
1

This probably has been discussed before, but I would like to discuss one issue with the new semver versioning approach:
It’s good that yii switches to semver but IMO the new version is much more: It’s a huge architecture change, thus could also be considered a completely new library.
The major version number in semver signales breaking changes - but not to what degree they break.
I want to compare this with “Typo3”: This CMS was originally just “TYPO”. After Version 3 it stayed “TYPO3”, but with version 3, 5… etc. There were some breaking changes between the versions, but no complete architecture change. They added functionality but maintained BC to some degree.

What if the new Yii was considered a new product (i.E. Yii3), becoming Yii3 version 3.x. The next big, not completely compatible update Yii3 4.0 etc.

Yii3 may change to Yii4 much later, when major architecture changes happen again which may need complete rewrites.

This might sound like a silly discussion, but I see some trouble in extension names and namespaces. If the “Generation” of the framework is not part of the framework they cannot be used together in one application anymore (which is now still possible with some hassle between Yii1 and Yii2).

So what’s your thoughts about using the “generation” as part of the product name, keeping it as long things stay “almost” compatible:

yii3-xxxx for package names
and Yii3\xxxx for namespaces.

So basically the discussion is about taking the next major architecture change in - let’s say 5 or 10 years - into account.

Edit: But yes, I understand that it can be confusing to have a number in the “product name” and in the version number which do not necessarily match.

1 Like
2

This was already discussed at GitHub:

I think that goal should be to not make such big architectural changes anymore - changes should be introduced step by step. Right now lack of sane migration path between Yii 1.1 and Yii 2 is a big problem, and it seems to be even worse in case of migration from Yii 2 to Yii 3. If Migration to Yii 4 will require another rewrite of the entire app, this is a big indicator to not use Yii in any long-term project.

3

I agree that such major changes should not be done anymore - but who knows how “modern” architecture looks in 5 or 10 years.

When you look at all the libraries out there they have different approaches:

  • Either they stay in their original architecture not taking any risk of breaking changes (They look a bit old-fashioned now)
  • Or they do not really care about breaking changes - then it’s a nitemare using them
  • Or they carry a load of “proxy-stuff” to stay compatible with older versions but still go forward.

I think the last one is the best approach, but it can be a maintenance nitemare and nobody really knows what’s still safe to use and what will fade away over time.

When Yii"3" came up I hoped for as little architecture changes as possible. Noticing the major changes I just considered it a “different framework” (it’s not Yii anymore - It’s Yii3).

The versioning is not a big deal for me - but rather a discussion about “how to handle breaking changes” and how to handle “huge architecture changes”.

Unfortunately semver does not really make a difference:

First digits: Things break (If it’s just about a few changes or about a whole rewrite is not specified)
Second digits: New features, but things should not break
Third: No big deal at all.

So my approach was about a counter “above” the versioning - cases when it’s basically a new framework.

But if it really can be prevented in the future it’s fine to stick wih Yii and semver only. I am just not sure if it really can be done :wink:

4

Should not happen for 3.0 → 4.0. This time the goal is create a solid foundation based on PSR standards. Maybe some parts would change and there will be breaking changes in 4.0 but it should not be of the same scale ever again (except PHP itself would change dramatically).

5

My personal preference is to leave the name as “Yii”. There will be some confusion but I don’t think it will stay for long.

2 Likes
6

But we could introduce new namespace, like yiisoft instead of yii. It may help with migrating from Yii2 to Yii3 (since you will be able to use two frameworks at the same time).

1 Like
7

That was basically my my main concern.
I do not really have a problem with Yii alone if things stay almost compatible for a while. And I also do not worry about Yii 4.0 - but what about Yii 7.0 or something like that?
So the basic idea was to have the “Generation” of the framework in the product name (and namespaces/packages). It could basically stay the same all the time as Yii does not change dramatically. The next version could just be Yii3 V1.0, and and the anticipated Yii 4.0 is just Yii3 2.0 and so on and the “Generation” does not change as long as long there is no general design change.
But It’s not such a big deal. To me both concepts are OK. And following PSR might really make things a bit more stable.

8

Hello Alexander, team and all the community.

I spent some time to analyze this, and I took the liberty to share it here with you.

As the architecture changed, I consider this evolution/mutation to a renewed framework and not only version so there are my thoughts, my vision:

• yii is the name and should be maintained.
• the now adopted versioning is perfect. X.x.x
• two Major old versions are now known by the community as a product, as a brand and not only as a version, it is so as we all call it yii1 and yii2.

The solution to avoid this in the future and not call it yii3 and make confusions toward versioning and next major versions is to change how framework graphical identity is presented, with the arrival of Yii number three.

yii framework as the product has a logo, an identity an image, that is old, but known for Yii since its version1 that should be maintained for yii1 and yii2, but now as products or releases.
So they will carry a brand.

With the arrival of Yii 3.0, as a major architectural move, the all framework change so much, the identity as release and product should also change.
It must, in my view change and mutate to brand identity so Yii would be known as Yii, with a new logo, a new identity, and still there will be yii1 and yii2 old ones and Yii(new version) available as a brand of Yii.
I am a coder, a designer too, and I thought it would be gentle to share with you, my vision.
I hope it will make at least think the community and Alexander and team about Yii framework Identity
As YIIFRAMEWORK that have three products [yii1] [yii2] [yii] for now on:

yii3-01
yii3-014962×3509 443 KB

6 Likes
9

@muitosefala Thank you so much for sharing your thoughts and design ideas!

1 Like
10

If approved, the icon in fontawesome would be great

2 Likes
11

machour thank you for taking time in having a look!
vanhelvzla You’re fabulously right!
Thank you very much for your position on my vision. But one thing is certain, even if it’s not the right one for the framework, you’ve had a genius trait.
In terms of marketing, nothing would be stronger than the icon already being part of the fontawesome icons.
You made me think about this again, I hope the Yii team sees your post. Thank you.

2 Likes
12

You could place the logos in png to download them so they are not official, they are great, the yii 3.0 is fantastic I imagine it favicon.

Only with the logos could I easily tag which version of yii I am using visually in the repositories, including the image to share on social networks.