Starting version for framework / packages

So far we’ve decided that SemVer will be used for both framework and libraries but there are still two things to decide.

What version to start framework-specific packages (yiisoft/yii-*) with?

  • 1.0.0
  • 3.0.0

0 voters

What version to start framework-independent packages (yiisoft/*) with?

  • 1.0.0
  • 3.0.0

0 voters

I’d follow SerVer (related to framework) also for libraries to identify immediately specific version reference between library and framework.

See an example.

Now we have Yii 3.0.0 and an year later we will have Yii 4.2.4 that introduces some BC.

yii-bestlib for Yii 3.0.0 is 1.0.0 and to handle BC of Yii 4.2.4 we update to 1.0.1.

Now, I want to continue to support Yii 3.x version for yii-best-lib. What will be yii-best-lib next version?

You have dependencies in composer.json so in the yii-best-lib you have to specify what framework versions it is compatible with. Trying to align versions would not allow us going SemVer because framework could be 4.x.x while extension may be 6.x.x and vice versa.

Starting with 3.0.0 has a single pro that it would give a hint at the very start. That’s it.

2 Likes

That is quite a lot. I can’t even imagine confusion created by releasing framework-specific packages using 1.0.0 as a version. You will not even be able to say which version of Yii you’re using. :smiley:

I was under impression that we want to group whole new Yii concept under name “3” which in this case would rather mean “3rd approach”. With this idea semver should start with 1.0.0 (and that is why I voted for it in first place). This would allow to make v2.x, v3.x, v4.x and so on and it would be still “Yii 3”.

Starting with 3.0.0 shows that Yii goes the Symfony way and this “3rd approach” concept is no more as Yii embraces its ecosystem and does not divide developers anymore. I like it better so I switched my voice to 3.0.0.

1 Like

I don’t see problems to keep lib major version aligned to framework major version.

Why should lib major version be different from framework major version?

I hope you’re wrong. Having Yii 3 v2.0.0 will be just source of confusion and unnecessary compicity. AFAIK that was the reason why yii2- prefix was was dropped and we started with repositories and packages without number in its name.

I suggest to take a look at yii2- official extensions. 2.1.0 was reserved for next major release of Yii framework, but some of extensions already have 2.2.0 release, so they’re 2 versions ahead.

1 Like

I guess you haven’t read my post till the end. I think 3.0.0 and the whole tier-agnostic approach is better.

Most probably both will develop with different speed and introduce different BC-breaking changes so aligning versions would be nightmare.

Why different development speed should be a problem?

To handle BC, you can lock version inside composer.lock.

I referred to concept in first part of your post (I’m still not sure what was the final decision). Nothing personal. :slight_smile:

Because you can’t just release new major version of package, you need to wait for major release of core framework (this may stop some major improvements for years).
Or you need to release dumb major release, which does not break BC at all, just because framework released major release and package needs to go in line with framework.

It didn’t work for Yii 2, and definitely will not work for Yii 3+.

Exclusively for this case, we can use major version to be aligned with framework version and minor to handle library BC.

So:

Major : Framework
Minor : BC
Version : x
Patch : y

It is not really SemVer (because in this case minor handle BC inside the library), but it keep reading clear.

So I guess this is not an option. It does not make sense to release framework-independent packages if they’re using custom versioning rules specific to framework. Yii 2 had something like this and it was dropped because it was confusing (almost everyone follows semver, so having 2.1.0 as a major release was surprising even for Yii users) and does not work so well with composer constraints.

1 Like

Yes, this is not an option, at least for yii related libraries.

Otherwise, we should have

YiiBestLib3 v.1.0.0 (compatible with Yii3)
YiiBestLib4 v.1.0.0 (compatible with Yii4)

because I think that having a single package (ex. YiiBestLib) makes difficult to maintain BC inside library and framework, but I don’t like it.

This is the ideal time to make definitive decisions, the new framework is in development, being a new agnostic framework we should not have dependence problems, I would like it to be simply Yii as commercial name in its version 1.0.0, with respect to Yii v.2.0 your repositories start with yii2-lib so we should not have problems, any repository without yii2 should be the new Yii.

IMO, the framework-independent libraries are not relative to any yii-* or frameworks/projects, it seems no reasons to keep their’s version relative to yii3, or yii4 etc.

2 Likes

Oops I accidentally voted 3.0.0 for framework-independent packages ( yiisoft/* ), but intended to vote 1.0.0. Can’t seem to change my vote afterwards :frowning:

Since this is Yii 3, I do feel we should use 3.0.0 for framework-specific packages ( yiisoft/yii-* ). Otherwise this will be very confusing for (new) users. I mean how does this sound: Get started with Yii version 3 by installing yiisoft/yii-web version 1. Right? Eeeh?

Click “Hide results” and then you could revote.:grinning:

1 Like

Version of the package won’t be specified in installation instructions anywhere so it will be:

Get started with Yii by installing yiisoft/yii-web.