|
12
|
Hi all, Anybody know a reason that prevents the removal of the vendor directory as well as the ZendSkeletonApplication submodules installation workflow? Seem to me that making ZendSkeletonApplication installation similar to what right now is zf-apigility-skeleton installation we will gain in uniformity. I could create PRs to deal with this, but as Maks3w point me out ( https://github.com/zendframework/ZendSkeletonApplication/pull/235), an email here will allow others developers give theirs opinion about this issue.
Thanks Frank
|
|
There all still many people which dont use composer...(look through different zf2 modules where people have problems when not using composer)
Let all options open for people.
E.g. i always have to switch my company network to public because of a proxy and port filter...
Am 20.01.2014 20:52 schrieb "Frank Cancio" < [hidden email]>:
Hi all, Anybody know a reason that prevents the removal of the vendor directory as well as the ZendSkeletonApplication submodules installation workflow? Seem to me that making ZendSkeletonApplication installation similar to what right now is zf-apigility-skeleton installation we will gain in uniformity. I could create PRs to deal with this, but as Maks3w point me out ( https://github.com/zendframework/ZendSkeletonApplication/pull/235), an email here will allow others developers give theirs opinion about this issue.
Thanks Frank
|
|
I don't get the advantage of using git submodules over composer regards the accessibility, both need Internet access.
Can you be more explicit about the problem people have with zf2 modules when not using composer and how git submodules could help us to solve those problems?
|
|
This post has NOT been accepted by the mailing list yet.
|
|
CONTENTS DELETED
The author has deleted this message.
|
|
I don't think this achieves anything and only limits the installation options.
G
|
|
Thanks to all for your replies.
As I said, the main advantage is: "make easier the maintenance. Right now after do `git clone git://github.com/zendframework/ZendSkeletonApplication.git --recursive` one end with a very old ZF2 version in 'vendor/ZF2' dir, more specifically this commit: https://github.com/zendframework/zf2/commit/6022f490695b1c835070d9e5a81b45dc20b4a51c". That commit is a 9 month old ZF2 version.
So right now we are delivering to users that choose git submodule workflow a stale ZF2 version, the only way to guarantee that this will not happen again is be very disciplined and with each release of ZF2 update ZendSkeletonApplication ZF2 submodule conf, mean waste time in maintenance. In change of what? Martin point me some domain and port blocking stuff, still git submodule workflow use 443 and 9418 while composer workflow use 80 and 9418, the only different is that one use github.com and the other use packagist.org + github.com domain.
I think that whatever thing we decide here, will get changes to ZendSkeletonApplication or to zf-apigility-skeleton
|
|
Why not just update ZendSkeletonApplication with latest ZF2 submodule and fix any bugs that result?
I refuse to use composer for my ZF2 projects. It's specifically rejected by my enterprise requirements.
|
|
Enterprise requirements??? #areyousure
I highly recommend using Composer.
Eddie Abou-Jaoude, BEng, MSc
Jaoude Studios Ltd LAMP & Zend Framework Consultant
Why not just update ZendSkeletonApplication with latest ZF2 submodule and fix any bugs that result?
I refuse to use composer for my ZF2 projects. It's specifically rejected by my enterprise requirements.
|
|
With slow moving corporations, it's quite often that you can't use the latest and best tools. I'm just happy we can finally use PHP 5.4 here as of January for new projects (even if it's 5.4.14 and getting a bit aged)
We can't technically use composer, as it's not on the allowed applications list, and neither getcomposer.org nor packigist.org are whitelisted for corporate network access.
So, I can believe that it's the same elsewhere where corporate IT policies/lawyers have reign. For example, we are allowed only to use very specific versions of YUI, jQuery, ZF2 (not the entire library, only certain components are allowed x.x), etc. And with the deployment process taking anywhere from 3-12 months after we make a fix / develop new features -- we tend to follow those allowed version numbers to the T to prevent it being bounced back by legal, or certification teams during the process, delaying deployment further.
We got access to PHP 5.3 just last year. So that was a wonderful day for us.
|
|
With slow moving corporations, it's quite often that you can't use the latest and best tools. I'm just happy we can finally use PHP 5.4 here as of January for new projects (even if it's 5.4.14 and getting a bit aged)
We can't technically use composer, as it's not on the allowed applications list, and neither getcomposer.org nor packigist.org are whitelisted for corporate network access.
So, I can believe that it's the same elsewhere where corporate IT policies/lawyers have reign. For example, we are allowed only to use very specific versions of YUI, jQuery, ZF2 (not the entire library, only certain components are allowed x.x), etc. And with the deployment process taking anywhere from 3-12 months after we make a fix / develop new features -- we tend to follow those allowed version numbers to the T to prevent it being bounced back by legal, or certification teams during the process, delaying deployment further.
We got access to PHP 5.3 just last year. So that was a wonderful day for us.
|
|
Wow were do you work? That does not sound very Agile or Continuous Delivery (3-12months) #Ifeelyourpain :(
Eddie Abou-Jaoude, BEng, MSc
Jaoude Studios Ltd LAMP & Zend Framework Consultant
With slow moving corporations, it's quite often that you can't use the latest and best tools. I'm just happy we can finally use PHP 5.4 here as of January for new projects (even if it's 5.4.14 and getting a bit aged)
We can't technically use composer, as it's not on the allowed applications list, and neither getcomposer.org nor packigist.org are whitelisted for corporate network access.
So, I can believe that it's the same elsewhere where corporate IT policies/lawyers have reign. For example, we are allowed only to use very specific versions of YUI, jQuery, ZF2 (not the entire library, only certain components are allowed x.x), etc. And with the deployment process taking anywhere from 3-12 months after we make a fix / develop new features -- we tend to follow those allowed version numbers to the T to prevent it being bounced back by legal, or certification teams during the process, delaying deployment further.
We got access to PHP 5.3 just last year. So that was a wonderful day for us.
|
|
I apologize, I thought --branch would work with any treeish, but it appears I was mistaken. Back when I was doing benchmarks between versions, I was running git checkout TAG && git submodule update, which admittedly is not any different than the same process with composer.
That's not my primary point, though. I just don't see value in limiting the options, especially if I have no problem getting back into maintaining the skeleton tags.
Thanks,
Evan
Sent from my phone. Please excuse any typos or unintentional auto-corrections.
|
12
|