Base implementation

[Horat1us]

#1

[rob006]

It does not solve yiisoft/yii2#14973 at all. And it requires PHP 5.6 so it cannot be used for Yii 2.0 tests.

[samdark]

Yes. Should be 5.4.

[Horat1us]

What should be done to fix this?

[cebe]

What should be done to fix this?

see #1 (comment)

and https://github.com/yiisoft/yii2/blob/master/tests/compatibility.php

[schmunk42]

I just noticed that having 4-digits in the version number is a bit tricky.

While would give you all updates for version 2.0.*, when using three digits (like ~2.0.13)
But it gives you only updates of version 2.0.13.*' when using four digits (~2.0.13.1`) and this is not what we want here.

Compare the output of the get an example:

• https://semver.mwl.be/#?package=yiisoft%2Fyii2&version=~2.0.14&minimum-stability=stable
• https://semver.mwl.be/#?package=yiisoft%2Fyii2&version=~2.0.14.0&minimum-stability=stable

For Yii the situation becomes even worse with ^ since this gives you all updates up to 2.999.* no matter if you are using three or four digits, which is problematic in Yii-terms, since the second digit is effectively the major version number.

There'll be many extensions which will be either compatible with 2.0 or 2.1 and there's actually no operator to define a range for >= 2.0.15.1 < 2.1.0.0.

Given that we should really think about releasing a version 3.0 instead of 2.1 - even if this is also somehow "ugly". I can't imagine composer nor semver adopting a new operator or four-digit syntax soon.

The only other alternative I can think of is using -p1, -p2 for patch releases.

CC: @samdark @cebe

[schmunk42]

See #2 (comment)

[Horat1us]

I suppose releasing 3.0 instead of 2.1 good idea, because in my company we have a lot of extensions for Yii2 (> 40 repositories). We are not able to update after each minor release. Now we use ^2.0.13 for extensions Yii dependencies instead of recommended ~2.0.13

[rob006]

@Horat1us You should fix constraints in your extensions. I'm pretty sure that there are many extensions with * as "constraint", but this is not a reason to release next framework version as a separate package.

@schmunk42 What we will get after releasing 2.1 as 3.0? Yii 2 3.0?

[schmunk42]

@rob006 Not as a separate package. The problems is, that there is no operator like "§2.1.x.y" which would update patch-versions, but not minor (speaking in semver terms).

Yes, yiisoft/yii2:3.0.0

[rob006]

Not as a separate package. The problems is, that there is no operator like "§2.1.x.y" which would update patch-versions, but not minor (speaking in semver terms).

Why would you need such operator? Patch versions (2.0.15.x) does not provide any new features, why do you want to specify it in constraint?

Yes, yiisoft/yii2:3.0.0

I'm talking about "human" name. If you have a sentence like "Yii 2 Core Framework Code Style" how it will look for a 3.x line? "Yii 2 3.x Core Framework Code Style"?

[schmunk42]

Patch versions (2.0.15.x) does not provide any new features, why do you want to specify it in constraint?

The fourth digits aren't patch versions in semver, only in Yii-terms. AFAIK they are not even covered by semver.

I'm talking about "human" name. If you have a sentence like "Yii 2 Core Framework Code Style" how it will look for a 3.x line? "Yii 2 3.x Core Framework Code Style"?

Hard to say and I am absolutely open for discussion, maybe I'd move the "2" to "yii", like Yii2 Framework 3.0 Codestyle?

[rob006]

@schmunk42 You did not answer my question. Why do you want to specify constraint as >= 2.0.15.1 < 2.1.0.0 instead of just ~2.0.15 in your library? 2.0.15.1 should not contain any features not available in 2.0.15.0, so what is the point?

[schmunk42]

2.0.15.1 should not contain any features not available in 2.0.15.0, so what is the point?

You might need to depend on 2.0.15.1 (and above) not only 2.0.15.0 (and above), especially when there are patches. Why else would there be a new version?

This is actually the most common case, when you take the current versioning scheme.
You usually want >=2.0.15.1 < 2.1.0.0.

[rob006]

~2.0.15 will be valid for 2.0.15.0, 2.0.15.1 , 2.0.15.2, 2.0.16.0, 2.0.16.1 , 2.0.16.2 and so on. The only difference between ~2.0.15 and >=2.0.15.1 < 2.1.0.0 is that >=2.0.15.1 < 2.1.0.0 will not allow you to install 2.0.15.0. Why do you want to disallow this version in library? 2.0.15.0 should contain the same set of features as 2.0.15.1. It may have less bugs, but this should not be concern of library.

[Horat1us]

When this package use ~2.0.13.1 I wasn't able to install Yii 2.0.15 on my project, thats why I made 7ea2f00 commit

[schmunk42]

You're simply overreacting and stretch the truth.

I am not ignoring the facts ;)

Yii does not follow semver anyway (minor releases breaks BC so often...),

Yii does in my opinion a much better much in maintaining BC than most other software I used.

Yii did only do patch releases for now, actually. This is confusing and annoying developers.
Using four-digits is an ugly unsupported hack. Hotfixes that have been released as such should have been suffixed with -p1, -p2 - which is also not covered by semver (AFAIK), but fully supported by composer.

specifying patch release is not a basic task (it is edge case, and composer fully support such cases),

It should not be that hard, but it is, because of the problems outlined above - it's self-inflicted.

and invalid constraints in extensions is a problem of these extensions, not framework itself

The framework should not make it hard for the developers to pick the right constraint from the documentation, but obviously it is.

You basically expecting some kind of rebranding - replace Yii framework by Yii2 Framework.

I am not expecting this, the situation is simply very unsatisfying. I actually think of Yii Framework as Yii1 and Yii 2.0 Framework as Yii2.

---

What's about saying we have now Yii 2:2.0.15 and we'll transition to Yii 2:3.0.0?

[rob006]

I am not ignoring the facts ;)

Yeah... This discussion really reminds me this one: yiisoft/yii2-app-basic#112 :D

Yii did only do patch releases for now, actually. This is confusing and annoying developers.
Using four-digits is an ugly unsupported hack. Hotfixes that have been released as such should have been suffixed with -p1, -p2 - which is also not covered by semver (AFAIK), but fully supported by composer.

1. Yii versioning (what is minor and what is patch release) is explained here: https://github.com/yiisoft/yii2/blob/master/docs/internals/versions.md . Changing versioning policy on every major release can be commented only in one way: https://xkcd.com/927/ ;)
2. Using 4-digits versions is completely normal - even composer normalizes versions in this way:

        "name": "twbs/bootstrap",
        "version": "v3.3.7",
        "version_normalized": "3.3.7.0",

3. -p1 is covered by semver - it is treated as pre-release. So 2.0.15-p1 is unstable version of 2.0.15. Definitely bad choice for patch release. But AFAIK composer does not follow this convention (except some common suffixes like -beta).

The framework should not make it hard for the developers to pick the right constraint from the documentation, but obviously it is.

1. There is a template for extension with valid constraint: https://github.com/yiisoft/yii2-gii/blob/f8b912fee3c1924ffcc3dde23b0cf7117318713c/src/generators/extension/default/composer.json#L14
2. Same for app templates.
3. Switching to 3-digits versioning will not solve any problem. Using ^3.0 (recommended constraint for semver) is not safe anyway, since 3.1 may bring BC break. You always need to consider how stable is used dependency and what is it's versioning policy and BC promise. You cant blindly assume that package follows semver, since like 95% packages do not really follow it, even if versions looks like semver.

[schmunk42]

Yeah... This discussion really reminds me this one: yiisoft/yii2-app-basic#112 :D

🤣 Thought about that a minute ago, I still can't believe people are working like that...

I know about the policy, but the xkcd does not really fit. This one is slightly better https://xkcd.com/242/

2. Using 4-digits versions is completely normal - even composer normalizes versions in this way

Which other large PHP project does that?
If composer wouldn't do that internally, we could not even use that.

-p1 is covered by semver - it is treated as pre-release.

Really? If so, composer handles it completely wrong, since it's treated as a patch release which comes after the stable version without suffix.

There is a template for extension with valid constraint

Would not be working as expected if the version would be updated to ~2.0.15.2 (latest release) and would be almost guaranteed breaking if it would be ^2.0.15.2.

Switching to 3-digits versioning will not solve any problem.
Using ^3.0 (recommended constraint for semver) is not safe anyway, since 3.1 may bring BC break.

I think otherwise, at least we could choose an operator which makes sense.

You always need to consider how stable is used dependency and what is it's versioning policy and BC promise. You cant blindly assume that package follows semver, since like 95% packages do not really follow it, even if versions looks like semver.

It's not about some package on the web, it's about the Core Framework version.

[rob006]

Would not be working as expected if the version would be updated to ~2.0.15.2 (latest release) and would be almost guaranteed breaking if it would be ^2.0.15.2.

It will also not work correctly if it will be updated to 2.0.15.2, * or magic. That's the thing - you cannot put some random values as a constraint. If you don't know the syntax, result may be always surprising to you :)

[Horat1us]

@samdark using 21.. is good idea, because it's less confusing (in case of 3.0), and will not break packages that use ^2.0.XX (using ~2.0.XX really not comfortable in case of using a lot of packages: we need to release version for each package after each Yii2 patch release)

[cebe]

There'll be many extensions which will be either compatible with 2.0 or 2.1 and there's actually no operator to define a range for >= 2.0.15.1 < 2.1.0.0.

its possible to define such a constraint like this ~2.0.14,>=2.0.14.2. (using 2.0.14 as the example to show that upgrade to 2.0.15 works:

https://semver.mwl.be/#?package=yiisoft%2Fyii2&version=~2.0.14,%3E%3D2.0.14.1&minimum-stability=stable

[samdark]

It is but it's quite counter-intuitive and complicated.

[cebe]

It is but it's quite counter-intuitive and complicated.

given that patch releases are hotfixes with only small changes, its quite rare that someone would need to require a specific hotfix version as the minimum required version. If its still needed, it can be solved like this. Not a reason to change the overall versioning strategy because of a rare occurence.

[schmunk42]

Not a reason to change the overall versioning strategy because of a rare occurence.

Honestly speaking, that was not so rare given the past releases. The current versioning makes it just harder for you as maintainers to do releases.

[cebe]

Honestly speaking, that was not so rare given the past releases.

could you name more than one case, where a library needs to depend on a specific patch version of Yii?

The current versioning makes it just harder for you as maintainers to do releases.

I don't get what you want to say. Yii versioning works well from my side :)

[schmunk42]

Look at the current state of https://github.com/yiisoft/yii2/releases

• 2.0.15.1 hotfix release
• 2.0.13.3 hotfix release
• 2.0.12.2 hotfix release
• 2.0.15 security fix release
• 2.0.13.2 security fix release
• 2.0.12.1 security fix release
• 2.0.14.2 hotfix release
• 2.0.14.1 hotfix release
• 2.0.14
• 2.0.13.1 hotfix release

yiisoft/yii2@2.0.14.2...2.0.15
Actually a typical (semver) patch (fix for SQL injection CVE) IMHO - why is this a (Yii minor) release?
For which lower versions is this fixed 2.0.13, 2.0.12, why not 2.0.14?

yiisoft/yii2@2.0.15...2.0.15.1
Changelog says it's a bug, it looks like an enhancement to me; issue still open
yiisoft/yii2#15931

When I start depending on ~2.0.15 and I realize that I need to depend on ~2.0.15.1 my whole update workflow breaks (or works differently), if I don't adjust the constraint.

The missing zero is utterly confusing, why is it not added all the time?

[addon]

Why is the security fix in some versions a (Yii) patch and sometimes a (Yii) minor release?
AFAIR there was a similar thing with the CVE before that.

[cebe]

yiisoft/yii2@2.0.14.2...2.0.15
Actually a typical (semver) patch (fix for SQL injection CVE) IMHO - why is this a (Yii minor) release?
For which lower versions is this fixed 2.0.13, 2.0.12, why not 2.0.14?

The 2.0.15 release is a tricky one, because it is

1. a security patch, which needed to get adopted as fast as possible
2. the patch breaks BC in some ways

We released the fix as 2.0.15, with news announcement to get attention. We do not make announcement for patch releases and it is a breaking change. Thats the reason for 2.0.15.

We also needed to make sure it gets applied to as many projects as possible, so we want people to allow to stay on the yii minor they are currently on and still apply the patch, thats the reason for 2.0.13.2 and 2.0.12.1. the difference between 2.0.14.2 and 2.0.15 is the security patch, so there is no point in releasing 2.0.14.3 for it.

yiisoft/yii2@2.0.15...2.0.15.1
Changelog says it's a bug, it looks like an enhancement to me; issue still open
yiisoft/yii2#15931

2.0.15.1 lowers the impact of the BC break in the security patch. Due to the patch AR::refresh() was broken. Its still open because the fix in 2.0.15.1 does not cover all cases.

When I start depending on ~2.0.15 and I realize that I need to depend on ~2.0.15.1 my whole update workflow breaks (or works differently), if I don't adjust the constraint.

in an application I recommend to use a fixed constraint and do yii upgrades manually. Upgrading Yii always includes reading the UPGRADE.md and check for breaking changes in some way. So for an applicion the upgrade workflow should not be handled by composer constraint imo.
For a library using the constraint I explained above should work fine.

The missing zero is utterly confusing, why is it not added all the time?

Yii versioning scheme has grown over time, the first two years or so, we did not do any patch releases. We introduced patches when we finalized versioning scheme and automated the release process.
We just continued with the naming of normal releases as they were before. patches are added as needed and there is no technical requirement for adding a 0 to the version.

I don't say that Yii versioning scheme is perfect. There are things that can be improved to reduce confusion. But switching to a completely different scheme seems to be an unnecessarily radical step to me.

[samdark]

Probably adding x.x.x.0 all the time will lower confusion.

[schmunk42]

Thank you for the detailed explanation.

But reading that makes actually convinces me even more that the current versioning should be changed.

We released the fix as 2.0.15, with news announcement to get attention. We do not make announcement for patch releases and it is a breaking change. Thats the reason for 2.0.15.
We also needed to make sure it gets applied to as many projects as possible, so we want people to allow to stay on the yii minor they are currently on and still apply the patch, thats the reason for 2.0.13.2 and 2.0.12.1. the difference between 2.0.14.2 and 2.0.15 is the security patch, so there is no point in releasing 2.0.14.3 for it.

In a nutshell, the change breaks BC, but for lower versions you pretend it's a (Yii) patch, so people apply a required but breaking change?! That's awfully intransparent.

Upgrading Yii always includes reading the UPGRADE.md and check for breaking changes in some way.

I heard, Yii is so complex that you can not really overlook it 🙊 So you can't really judge if a change affects you or not. Having a guidance from the core developers via semver, would greatly help here 😉.

there is no technical requirement for adding a 0 to the version.

Regarding the ~ operator it would be much better if upgrading would work in the same way, which is not the case, although I haven't tested if ~2.0.14 is the same as ~2.0.14.0 or not. I actually do not want to worry about it - this is so counter-intuitive.

I don't say that Yii versioning scheme is perfect. There are things that can be improved to reduce confusion. But switching to a completely different scheme seems to be an unnecessarily radical step to me

The more I dive into this topic, the more I come to the conclusion that this "radical" step is very neccessary.

[schmunk42]

Probably adding x.x.x.0 all the time will lower confusion.

But then there'll be no operator for getting (Yii) minor upgrades.

I apologize in advance, but get rid of this four-digit pain.

[cebe]

In a nutshell, the change breaks BC, but for lower versions you pretend it's a (Yii) patch, so people apply a required but breaking change?! That's awfully intransparent.

its bad, but it would be the same with semver...

Regarding the ~ operator it would be much better if upgrading would work in the same way, which is not the case, although I haven't tested if ~2.0.14 is the same as ~2.0.14.0 or not. I actually do not want to worry about it - this is so counter-intuitive.

I was not talking about the ~ operator. When using the operator, there is a difference between ~2.0, ~2.0.0 and ~2.0.0.0. There is no technical reason to add the 0 in general.

[schmunk42]

its bad, but it would be the same with semver...

Bad is not the point, it is intransparent and people think the can safely update their application because the fourth digit was raised, if you maintain multiple versions (like 2.0.12, 2.0.13, ...) you'd better off with versions like 2.2.17 and 3.1.5 where you could create new releases as 2.3.0 and 3.2.0. You have much more room to maneuver and it would be much clearer for the user what's to expect.

When using the operator, there is a difference between ~2.0, ~2.0.0 and ~2.0.0.0. There is no technical reason to add the 0 in general.

How is that difference not a technical reason, the opposite is the case, a version has to have three digits, period. Everything else results in really strange behavior, I know composer for quite some time and just stumbled upon these quirks by accident, because Yii now has three digit and for digit versions.

---

btw: We're including https://github.com/Roave/SecurityAdvisories in all of our projects, with semver you could easily mark versions with security issues in a clearly readable way. With the current scheme it's a pure mess.

[rob006]

btw: We're including https://github.com/Roave/SecurityAdvisories in all of our projects, with semver you could easily mark versions with security issues in a clearly readable way. With the current scheme it's a pure mess.

Could you explain what semver will change in this case? There is no equivalent for ^ or ~ operator for "and lower" constraint, so constraints would look exactly the same (except fixed 2 at the beginning).

[schmunk42]

Yeah true, regarding roave. I mixed up they are using conflict instead of require.

[cebe]

Bad is not the point, it is intransparent and people think the can safely update their application because the fourth digit was raised, if you maintain multiple versions (like 2.0.12, 2.0.13, ...) you'd better off with versions like 2.2.17 and 3.1.5 where you could create new releases as 2.3.0 and 3.2.0. You have much more room to maneuver and it would be much clearer for the user what's to expect.

if you have 2.3.1 and 2.4.2 in semver and you want to release a breaking security fix to both branches you have the same problem. Breaking in Semver means raising the first digit. You are lost here. Semver has the same problem.

[schmunk42]

if you have 2.3.1 and 2.4.2

Another reason for sticking closer to semver and having a clear policy which versions are supported.
A increase in a major version itself does not break any code, it merely tells the developer to read UPGRADING carefully.

I'd also rather see an increase like 2.4.2 to 2.5.0 and with a notice that there might be an issue, due to a security related bug than seeing 2.4.2.1.