Is time to remove ZendSkeletonApplication submodules?

[gsc-frank]

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

[ThaDafinser]

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

[gsc-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?

On Mon, Jan 20, 2014 at 6:33 PM, Martin Keckeis <[hidden email]> wrote:

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

[Marco Pivetta]

On 20 January 2014 21:48, Frank Cancio <[hidden email]> wrote:

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?

Just a note additional to that: assuming that the module is already autoloaded, you don't need any "special rule" even if you are not requiring a module via composer.

For example, if you copy-pasted a module in `module/MyStuff`, you can simply use composer's json to produce an autoloader for that:

{"autoload":{"psr-0":{"MyStuff":"module/MyStuff/src"}}}

Or you can setup your zf autoloader upfront if you prefer that.

I wouldn't get rid of the module cloning workflow though - it makes it simpler to work for companies that don't want to start using satis for smaller projects.

Marco Pivetta

http://twitter.com/Ocramius     

http://ocramius.github.com/

[gsc-frank]

On Mon, Jan 20, 2014 at 7:43 PM, Marco Pivetta <[hidden email]> wrote:

On 20 January 2014 21:48, Frank Cancio <[hidden email]> wrote:

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?

Just a note additional to that: assuming that the module is already autoloaded, you don't need any "special rule" even if you are not requiring a module via composer.

For example, if you copy-pasted a module in `module/MyStuff`, you can simply use composer's json to produce an autoloader for that:

{"autoload":{"psr-0":{"MyStuff":"module/MyStuff/src"}}}

Or you can setup your zf autoloader upfront if you prefer that.

I wouldn't get rid of the module cloning workflow though - it makes it simpler to work for companies that don't want to start using satis for smaller projects.

Maybe I don't express well myself... but I'm asking for inconveniences of get rid of the git submodule workflow as a way to pull ZF2 **while installing ZendSkeletonApplication**, I'm not asking for get rid of the git submodule workflow as a way to install ZF2 modules.

My question is, what benefices provide to us over its composer alternative the support of `git clone git://github.com/zendframework/ZendSkeletonApplication.git --recursive`?

What I propose is:

- Removing the section https://github.com/zendframework/ZendSkeletonApplication#using-git-submodules from the README.md

- Remove `vendor` dir from the ZendSkeletonApplication github repo

- Remove git submodule configuration

- Adjust root .gitignore file

What we will gain doing that? Well, beside the above mentioned uniformity with installation ways of zf-apigility-skeleton, 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

With these changes we will not be forbidden users install theirs own modules using git submodules workflow. The only effect will be that users can't use `git clone git://github.com/zendframework/ZendSkeletonApplication.git --recursive` out the box anymore (they actually can configure git submodules in theirs local clones to pull ZF2).

My intention is end with similar installation alternatives in zendframework/ZendSkeletonApplication and zfcampus/zf-apigility-skeleton. So if at the end we decide that for some reason is useful keep the git submodules workflow as a way to pull ZF2 as part of the installation process of ZendSkeletonApplication, we should consider add it to the zf-apigility-skeleton too.

Thanks!

Frank

 

Marco Pivetta

http://twitter.com/Ocramius     

http://ocramius.github.com/

[Marco Pivetta]

On 21 January 2014 04:07, gsc-frank [via Zend Framework Community] <[hidden email]> wrote:

Maybe I don't express well myself... but I'm asking for inconveniences of get rid of the git submodule workflow as a way to pull ZF2 **while installing ZendSkeletonApplication**, I'm not asking for get rid of the git submodule workflow as a way to install ZF2 modules.

Whoops, my bad! :|
 

My question is, what benefices provide to us over its composer alternative the support of `git clone git://github.com/zendframework/ZendSkeletonApplication.git --recursive`?

There's some companies/users that still don't use composer for <insert-reason-i-do-not-understand-here/>. And yes, composer does not support package signing yet, so that is also quite a problem.

I'm overall +1 for removing this way of installing things - I don't see a (meaningful) way of building larger applications in PHP without composer nowadays.

 

What I propose is:

- Removing the section https://github.com/zendframework/ZendSkeletonApplication#using-git-submodules from the README.md

- Remove `vendor` dir from the ZendSkeletonApplication github repo

- Remove git submodule configuration

- Adjust root .gitignore file

Documentation needs adjustments as well



Marco Pivetta

http://twitter.com/Ocramius     

http://ocramius.github.com/

[ThaDafinser]

2014/1/20 Frank Cancio <[hidden email]>

I don't get the advantage of using git submodules over composer regards the accessibility, both need Internet access.

You are right about that. But e.g. it can be that a domain or port is blocked and another not.

 

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?

I never used the submodules to install and i don't know how much people actually use it. But through it's a skeleon, many different starting points are good IMO.

I don't see the effort here to remove it, through it's not that much code.

[Stefano Torresi]

CONTENTS DELETED

The author has deleted this message.

[Spabby]

I don't think this achieves anything and only limits the installation options.

G

On Tue, Jan 21, 2014 at 9:10 AM, Stefano Torresi <[hidden email]> wrote:

To be honest I don't see any advantage in your proposal, apart getting rid of one dotfile, and directory that your going to fill anyway... :-P

Seriously, it's nice to have options, and this one does no harm whatsoever!

Stefano Torresi
Web Developer

[gsc-frank]

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

On Tue, Jan 21, 2014 at 7:15 AM, Gary Hockin <[hidden email]> wrote:

I don't think this achieves anything and only limits the installation options.

G

On Tue, Jan 21, 2014 at 9:10 AM, Stefano Torresi <[hidden email]> wrote:

To be honest I don't see any advantage in your proposal, apart getting rid of one dotfile, and directory that your going to fill anyway... :-P

Seriously, it's nice to have options, and this one does no harm whatsoever!

Stefano Torresi
Web Developer

[バートレット理路]

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.

Richie Bartlett Jr (バートレット理路)

On Wed, Jan 22, 2014 at 1:14 AM, Frank Cancio <[hidden email]> wrote:

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

On Tue, Jan 21, 2014 at 7:15 AM, Gary Hockin <[hidden email]> wrote:

I don't think this achieves anything and only limits the installation options.

G

On Tue, Jan 21, 2014 at 9:10 AM, Stefano Torresi <[hidden email]> wrote:

To be honest I don't see any advantage in your proposal, apart getting rid of one dotfile, and directory that your going to fill anyway... :-P

Seriously, it's nice to have options, and this one does no harm whatsoever!

Stefano Torresi
Web Developer

[Eddie Abou-Jaoude]

Enterprise requirements??? #areyousure

I highly recommend using Composer.

Eddie Abou-Jaoude, BEng, MSc

Jaoude Studios Ltd

LAMP & Zend Framework Consultant

[hidden email]

http://www.jaoudestudios.com 

https://github.com/eddiejaoude

http://uk.linkedin.com/in/eddiejaoude

On 21 Jan 2014, at 16:23, バートレット理路 <[hidden email]> wrote:

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.

Richie Bartlett Jr (バートレット理路)

On Wed, Jan 22, 2014 at 1:14 AM, Frank Cancio <[hidden email]> wrote:

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

On Tue, Jan 21, 2014 at 7:15 AM, Gary Hockin <[hidden email]> wrote:

I don't think this achieves anything and only limits the installation options.

G

On Tue, Jan 21, 2014 at 9:10 AM, Stefano Torresi <[hidden email]> wrote:

To be honest I don't see any advantage in your proposal, apart getting rid of one dotfile, and directory that your going to fill anyway... :-P

Seriously, it's nice to have options, and this one does no harm whatsoever!

Stefano Torresi
Web Developer

[Garbage Dump]

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.

On Tue, Jan 21, 2014 at 8:27 AM, Eddie Abou-Jaoude <[hidden email]> wrote:

Enterprise requirements??? #areyousure

I highly recommend using Composer.

Eddie Abou-Jaoude, BEng, MSc

Jaoude Studios Ltd

LAMP & Zend Framework Consultant

[hidden email]

http://www.jaoudestudios.com 

https://github.com/eddiejaoude

http://uk.linkedin.com/in/eddiejaoude

On 21 Jan 2014, at 16:23, バートレット理路 <[hidden email]> wrote:

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.

Richie Bartlett Jr (バートレット理路)

On Wed, Jan 22, 2014 at 1:14 AM, Frank Cancio <[hidden email]> wrote:

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

On Tue, Jan 21, 2014 at 7:15 AM, Gary Hockin <[hidden email]> wrote:

I don't think this achieves anything and only limits the installation options.

G

On Tue, Jan 21, 2014 at 9:10 AM, Stefano Torresi <[hidden email]> wrote:

To be honest I don't see any advantage in your proposal, apart getting rid of one dotfile, and directory that your going to fill anyway... :-P

Seriously, it's nice to have options, and this one does no harm whatsoever!

Stefano Torresi
Web Developer

[Carlos Koch-3]

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.

On Tue, Jan 21, 2014 at 10:09 AM, Garbage Dump <[hidden email]> wrote:

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.

On Tue, Jan 21, 2014 at 8:27 AM, Eddie Abou-Jaoude <[hidden email]> wrote:

Enterprise requirements??? #areyousure

I highly recommend using Composer.

Eddie Abou-Jaoude, BEng, MSc

Jaoude Studios Ltd

LAMP & Zend Framework Consultant

[hidden email]

http://www.jaoudestudios.com 

https://github.com/eddiejaoude

http://uk.linkedin.com/in/eddiejaoude

On 21 Jan 2014, at 16:23, バートレット理路 <[hidden email]> wrote:

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.

Richie Bartlett Jr (バートレット理路)

On Wed, Jan 22, 2014 at 1:14 AM, Frank Cancio <[hidden email]> wrote:

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

On Tue, Jan 21, 2014 at 7:15 AM, Gary Hockin <[hidden email]> wrote:

I don't think this achieves anything and only limits the installation options.

G

On Tue, Jan 21, 2014 at 9:10 AM, Stefano Torresi <[hidden email]> wrote:

To be honest I don't see any advantage in your proposal, apart getting rid of one dotfile, and directory that your going to fill anyway... :-P

Seriously, it's nice to have options, and this one does no harm whatsoever!

Stefano Torresi
Web Developer

[Eddie Abou-Jaoude]

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

[hidden email]

http://www.jaoudestudios.com 

https://github.com/eddiejaoude

http://uk.linkedin.com/in/eddiejaoude

On 21 Jan 2014, at 18:10, Carlos Koch <[hidden email]> wrote:

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.

On Tue, Jan 21, 2014 at 10:09 AM, Garbage Dump <[hidden email]> wrote:

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.

On Tue, Jan 21, 2014 at 8:27 AM, Eddie Abou-Jaoude <[hidden email]> wrote:

Enterprise requirements??? #areyousure

I highly recommend using Composer.

Eddie Abou-Jaoude, BEng, MSc

Jaoude Studios Ltd

LAMP & Zend Framework Consultant

[hidden email]

http://www.jaoudestudios.com 

https://github.com/eddiejaoude

http://uk.linkedin.com/in/eddiejaoude

On 21 Jan 2014, at 16:23, バートレット理路 <[hidden email]> wrote:

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.

Richie Bartlett Jr (バートレット理路)

On Wed, Jan 22, 2014 at 1:14 AM, Frank Cancio <[hidden email]> wrote:

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

On Tue, Jan 21, 2014 at 7:15 AM, Gary Hockin <[hidden email]> wrote:

I don't think this achieves anything and only limits the installation options.

G

On Tue, Jan 21, 2014 at 9:10 AM, Stefano Torresi <[hidden email]> wrote:

To be honest I don't see any advantage in your proposal, apart getting rid of one dotfile, and directory that your going to fill anyway... :-P

Seriously, it's nice to have options, and this one does no harm whatsoever!

Stefano Torresi
Web Developer

[EvanDotPro]

Hello,

On Tue, Jan 21, 2014 at 9:14 AM, Frank Cancio <[hidden email]> wrote:

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.

This is my fault. I was being very meticulous about keeping this up to date and in sync with upstream releases (including tags), but fell behind and haven't caught up. 

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?

This is what I was doing for a long time, and it was not a problem at all. It literally adds maybe 5 or 10 seconds to the tagging process for the skeleton. The larger issue has just been a lack of time dedicated towards maintaining this. I'll see if I can get the skeleton tagged and up to date in the next couple weeks. Honestly knowing that it's behind is what has been keeping me from doing it, so once it's caught up, I'm more inclined to stay up to pace with the releases. Like I said, it only takes a few seconds if someone bugs me to do it.

Personally, I still like being able to clone in a single command and get any release version + skeleton of ZF2 that I want. While there may not be a large subset of users who prefer or use the submodule, I don't think that alone justifies removing a viable, single-command installation option. I see less purpose in removing it.

Thanks,

Evan Coury

[gsc-frank]

On Tue, Jan 21, 2014 at 11:01 PM, Evan Coury <[hidden email]> wrote:

Hello,

On Tue, Jan 21, 2014 at 9:14 AM, Frank Cancio <[hidden email]> wrote:

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.

This is my fault. I was being very meticulous about keeping this up to date and in sync with upstream releases (including tags), but fell behind and haven't caught up. 

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?

This is what I was doing for a long time, and it was not a problem at all. It literally adds maybe 5 or 10 seconds to the tagging process for the skeleton. The larger issue has just been a lack of time dedicated towards maintaining this. I'll see if I can get the skeleton tagged and up to date in the next couple weeks. Honestly knowing that it's behind is what has been keeping me from doing it, so once it's caught up, I'm more inclined to stay up to pace with the releases. Like I said, it only takes a few seconds if someone bugs me to do it.

I can help, I suppose that if you explain me what to do I can create some PRs saving you time.

 

Personally, I still like being able to clone in a single command and get any release version + skeleton of ZF2 that I want.

Hmm, evidently this can't be achieved with composer outbox. 

 

While there may not be a large subset of users who prefer or use the submodule, I don't think that alone justifies removing a viable, single-command installation option. I see less purpose in removing it.

After read all the scary corporation thing that Carlos wrote and take in consideration what Evan said about "get any release version", I think now that remove submodule workflow installation of ZendSkeletonApplication is not such good idea ;)

 

Thanks,

Evan Coury

[Tomáš Fejfar]

On Wed, Jan 22, 2014 at 2:55 AM, Frank Cancio <[hidden email]> wrote:

Personally, I still like being able to clone in a single command and get any release version + skeleton of ZF2 that I want.

Hmm, evidently this can't be achieved with composer outbox. 

Why so? You can install specific version from composer (https://getcomposer.org/doc/01-basic-usage.md#package-versions). And it's two commands instead of one for majority of users and three steps (clone, change composer.json version, composer). 

[gsc-frank]

On Wed, Jan 22, 2014 at 7:18 AM, Tomáš Fejfar <[hidden email]> wrote:

On Wed, Jan 22, 2014 at 2:55 AM, Frank Cancio <[hidden email]> wrote:

Personally, I still like being able to clone in a single command and get any release version + skeleton of ZF2 that I want.

Hmm, evidently this can't be achieved with composer outbox. 

Why so? You can install specific version from composer (https://getcomposer.org/doc/01-basic-usage.md#package-versions). And it's two commands instead of one for majority of users and three steps (clone, change composer.json version, composer). 

You are right, I don't see how with git submodule you can "clone in a single command and get any release version + skeleton of ZF2". At first I thought that you can do that with something like  "git clone git://github.com/zendframework/ZendSkeletonApplication.git --recursive --branch RELEASE_NAME", but I tested now and RELEASE_NAME can't be a tag (versions identifiers).

Just for the records... in cases where you don't need different ZendSkeletonApplication and ZF2 versions, the second step could be a ZendSkeletonApplication checkout (bringing to the working dir the appropriate composer.json file) instead of a composer.json edit.

[EvanDotPro]

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.

On Jan 22, 2014 5:10 PM, "Frank Cancio" <[hidden email]> wrote:

On Wed, Jan 22, 2014 at 7:18 AM, Tomáš Fejfar <[hidden email]> wrote:

On Wed, Jan 22, 2014 at 2:55 AM, Frank Cancio <[hidden email]> wrote:

Personally, I still like being able to clone in a single command and get any release version + skeleton of ZF2 that I want.

Hmm, evidently this can't be achieved with composer outbox. 

Why so? You can install specific version from composer (https://getcomposer.org/doc/01-basic-usage.md#package-versions). And it's two commands instead of one for majority of users and three steps (clone, change composer.json version, composer). 

You are right, I don't see how with git submodule you can "clone in a single command and get any release version + skeleton of ZF2". At first I thought that you can do that with something like  "git clone git://github.com/zendframework/ZendSkeletonApplication.git --recursive --branch RELEASE_NAME", but I tested now and RELEASE_NAME can't be a tag (versions identifiers).

Just for the records... in cases where you don't need different ZendSkeletonApplication and ZF2 versions, the second step could be a ZendSkeletonApplication checkout (bringing to the working dir the appropriate composer.json file) instead of a composer.json edit.