-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maintaining core extensions separately #7812
Comments
should be done already long time ago :) |
"API doc should be generated on-the-fly when releasing the core framework" |
+1 |
good idea |
So it's only about versioning? I mostly care about being able to clone everything at once to hack it. Looks good to me. |
👍 |
1 similar comment
👍 |
it should be done earlier but its nice to hear you and I believe that some new developer can join to developers team to focus on special extension and so new idea brings up by focusing on some specific part of a big project |
Remove Reasons:
But now it is even not possible to avoid |
+1 |
1 similar comment
+1 |
Good one 👍 |
👍 But... its not enough, all JS stuff should be removed to extensions include client side from validators, etc. But yes, currently main pain is |
+1 |
+1 for @creocoder |
@SDKiller, @creocoder while I understand why you want to avoid using |
Excellent allow deploy fixes and enhancements fastest way. 👍 |
This proposal sounds good at first, from a code/test organization perspective. But if the goal is to really speed up releases, this only works if this structure empowers more people to contribute in more meaningful ways than currently possible, including reviewing and accepting pull requests. Also, I wonder is it possible that core changes break some extension compatibility? (As I understand the core may not depend on an extension, but an extension may depend on the core. Unless I'm wrong there.) And who is responsible in that scenario for regaining compatibility? And how would they be aware? What would be the behavior of the CI for a pull request? Does it mean that when someone changes an extension that relies on a particular core api, that they must also submit tests to the core to ensure that api persists in future versions of the core? |
Good decision. Eventually it had to be done, so starting now is wize. With respect to external parts like Pjax. I advocate to put these in separate extensions too because of either limitations / or not using it / or the use of alternative packages like i.e Intercooler. About the fxp/composer-asset-plugin. This significant limitation on proper behavior of composer is also something that deserves attention on short term. If I could choose one thing to do first, it would be this. |
@adamaltman the current issues are
Proposed change solves it. Compatibility between extension / framework versions could be achieved if extension will specify framework version in its requirements. We're going to do it as well. CI will work for extensions i.e. extension will be tested with framework version specified in its |
@dynasource I'm afraid it could not be done in 2.0.x... Or probably I don't see how to do it w/o breaking changes. Anyway, it's a separate issue and it's better to discuss it separately. |
Yes, @samdark for issues 1 and 2, it's good. 👍 |
@SDKiller Thanks for pointing out the issue with pjax. I think we handle this in a separate issue because it involves breaking BC. In this issue, we will focus on resolving this subsplit issue and make sure no BC is broken. The following changes will need to be made for this issue:
|
|
@qiangxue minimizing dependencies |
@lynicidn that's separate issue. |
how u want check requirments? in all extensions put |
I think requirement checker should be made in application templates only. Or perhaps we should simply rely on composer dependency to check them. |
may be need add interface for checker and check before put in vendor/autoload.php ? |
I installed yii2-app-basic using Is that supposed to happen? I found it weird when I noticed that my vendor dir got committed. |
Right. |
Fixed. |
i think that Translation status should should take into due consideration status docs from extensions. what do you think about it? |
What do you mean? |
here : https://github.com/yiisoft/yii2/blob/master/docs/internals/translation-status.md It should have the status docs from extensions. sorry for my english. |
Yes. Should be updated... |
is it possible to further minimize yii's composer.json, ie. by making composer libraries such as cebe/markdown as suggestion instead of a requirement? |
@dynasource only by throwing out |
My 2 cents here. Yes it would be great to have packages not only as
separate repositories, but in future as separate components which can
be used without core.
At moment, when your project based on Yii 1.x , and when it's big
enough, you wont have time to re-write whole project at once. And
this situation makes me more careful in selecting packages I will
use.
One main ides now is to start replacing app parts which are depends on
Yii 1.x with stand alone components where it could. And leave Yii only
several global responsibilities: Handle request, render result.
I see this the only way possible in projects with big code base grow
and being rewriten seamlesly not in a "full rewrite" way.
And I hope Yii will get rid of this problem in future.
Thanks
|
As I understand it completely contradicts the philosophy of Yii. This framework of tightly coupled components with lots of conscious violation of many OOP principles (like SOLID) for practice reasons. If short independent components from Yii will not be interested to anyone who build systems with independent components. Yii is interesting as full stack framework and only as full stack.
I bet that this never will happen. |
Anyway I could use it as I wrote for Handling Request and
Response. Then I will be free in selecting other App components. Yii
allows it.
|
I could do so to, but never will do that. Just check http:https://stackphp.com/ . If you want free set of components you usually want microframework. Like Silex. Yii is full stack. Its different. And you know, choosing Yii for handling Request and Response only is really not smart option because there is much more better tools for that. Every tool have it niche. |
While there are good built in features to make simple and nice CRUDs
fast it will make sense =)
Agree Yii is a tool and it must be used wisely as any other.
|
+1 |
@cebe anything left for this one? |
@samdark automation of releases. I'd like to keep this open until done. |
also docs are not 100% fine. E.g. guide for extension is not rendered anywhere. |
closing this now. extension docs generation will be part of the new website. |
docs about project structure, versioning etc are now in https://github.com/yiisoft/yii2/blob/master/docs/internals/README.md |
In order to enable faster version releases and make core extensions more scalable, we are thinking to maintain each core extension and application template separately in individual github projects. Below is a preliminary plan. Before we execute it, we would like to have it reviewed by everyone to make sure we do not omit anything important. Thank you!
Tasks
/extensions
and/apps
fromyii2
repoyii2-dev
to keep BC (solved by dev command)Project Organization
yii2-gii
extension will be maintained inyiisoft/yii2-gii
project.Release and Versioning Policy
2.x.y.z
.2.x
: major releases, containing major features. May be BC-breaking. Release cycle is around 6 months. With news announcements. Project site will be updated.2.x.y
: minor releases, containing minor features and bug fixes. Must be BC with prior2.x.*
releases. Release cycle is around 1 to 2 months. With news announcements. Project site will be updated.2.x.y.z
: patch releases, containing bug fixes only. Must be BC with prior2.x.*.*
releases. Release cycle is around 1 to 2 weeks. No news announcement or project site update (unless it contains major/security issue fixes). The release process will be made mostly automatic.master
branch is the dev branch for the current major release. Once a new minor release is ready, create a maintenance branch named2.x.y
offmaster
.2.x.y.z
on2.x.y
branch to mark patch releases (including2.x.y.0
release).2.x.y
will be merged back tomaster
constantly.2.t-dev
. Once the next major release is ready, it will be merged tomaster
, and then create a2.t.0
branch offmaster
(the old2.t-dev
branch will be deleted to avoid confusion).yii2
and core extension/application projects are released independently of each other.yii2
and core extension projects follow the above versioning and branching policies.yii2-gii
may have the latest version number as2.0.5
whileyii2
is already at2.1.3
, even though currently they are all synchronized at 2.0.3.The text was updated successfully, but these errors were encountered: