yiisoft/yii-core

Packages name convention

fcaldarelli opened this issue ยท 9 comments

Starting from Yii3, all packages are named with "yii" prefix, for example yii-core, yii-db, etc..etc..

Will Yii version 4 (and next) have an own git branch for all packages? Otherwise, keeping this name convention, how will it be mantained the support (LTS) also for all previous versions?

Or is it planned to have yii4-* packages?

Or is it planned to have yii4-* packages?

The whole point of dropping yii2- prefix in favor of yii- prefix is to avoid having a version in the package name, so there will be no yii4- packages (at least there are no such plans at this moment :P). Separate lines will be maintained using branches and semver-compatible releases.

The only downside, is that if a package needs to break compatibility to evolve, it will have to bump its version to 4.x, which will be weird.

What is weird in bumping version on BC breaking release?

We could end up having yii-core 6.0 only compatible with db: 7.0 & active-record: 10.0.
While it's SemVer logical, it won't make a lot of sense to me.

Not sure how this would play out once yii-core needs to bump its own version.

I'll guess we'll wait and see, as we can't foresee how many times BC will get broken :)

While it's SemVer logical, it won't make a lot of sense to me.

We already got this in Yii 2.0 - there were 2.1.0 releases of extensions even if there was no 2.1.0 release of framework core (which would be major version bump, like 3.0.0 in semver).

Maybe should all core packages have same major version?

yii-core 6.x.y surely compatible with yii-db 6.a.b, yii-activerecord 6.c.d, etc.. ?

Maybe should all core packages have same major version?

What for? Independent release cycle is one of the main benefits from splitting framework into separate packages - more dynamic parts of the framework can evolve faster without waiting for the next major release of the framework, and more stable parts do not need to create pointless major releases that don't change anything, just to keep up with versioning of rest of the framework.

It is a composer's job to pick up compatible versions of requested packages, there is no point in creating superfluous restrictions for package versioning.

It's ok.

I think that for every yii-* packages, we need to create different branches to support the major version.

Then, how do you think to manage LTS of packages?

For example, we have yii-db v.3 , v.4 and v.5 that are compatible with yii-core v.3.

Starting from yii-db v.6, it is required yii-code v.4, that points to HEAD of master branch.

How will we support older packages version?

The idea is what @rob006 wrote. Independent releases, SemVer-ed dependencies. Maintaining multiple branches isn't a problem. We did 2.0.x.y releases with security fixes after 2.0.x+1 was already released.