Willing to maintain

[sagikazarmark]

Hey, are you still offering this?

I was planning something similar.

Would you allow me to do some rewrite? I would use a microframework instead of zend.

I am also thinking about writting a REST api.

[mnapoli]

Hey great news, yes this all seems really a good idea. Here is what I suggest:

• I've tagged 1.0.0 right now (didn't have any release yet), you can work on 2.0
• I'll give you access to the repository, feel free to do anything but please merge on master only a working version (i.e. I like the fact that people can download the zip and it just works, if master is broken the project will be broken for them)
• later we can consider moving the project to its own organization (e.g. for 2.0)

I've written that 3 years ago I don't think there's anything left to save ;)

[mnapoli]

Also feel free to do #8 if you want to.

[sagikazarmark]

Sure thing. I also usually keep trying the master branch working. I can imagine a possible teamup with pheanstalk. The main client, a monitor and possibly a console application to interact with beanstalk.

[sagikazarmark]

One thing I am not completely sure about is committing the vendor directory into the repo. For that case, I would rather create a ZIP and upload it when releasing the version. WDYT?

[judgej]

No, you don't commit the vendor directory. That is fetched by the developer or installer. You commit the composer.lock file, which contains the information needed to fetch known versions of everything into the vendor directory. You also commit composer.json that lists all the dependencies and ranges on versions of packages that composer will fetch.

[sagikazarmark]

@judgej you are right, this is how composer usually works. However @mnapoli wants that the user just downloads the ZIP file and it works without messing with composer. While this is an acceptable requirement, I don't think it should be done for the branch archives too.

Instead I would tag new releases regularly and create custom archives with installed dependencies.

[judgej]

It was certainly handy when you used to be able to upload arbitrary zip files to the release mechanism, then you could put together a complete build and release that.

Bur certainly keeping the repository reserved just for the source that is used to create the builds, will pay dividends when developing.

[mnapoli]

Regarding the vendor/ directory my POV is that as long that it's easy to download the latest zip containing everything ready to go we don't have to commit the dependencies. But that requires extra work, as you said either uploading manually the release every time, or setting up a release process with Travis to generate it (we've done it for Couscous, a little bit of work but it works fine).

[sagikazarmark]

My plan is to create a build script which builds a ZIP and a TAR archive which can be easily uploaded for releases. I would rather not automatize it as building process might differ from simply running composer install. For example assets (bootstrap, jquery) are going to be handled by Puli which supports symlinking files, while they must be copied for the archive.

It depends on our release cycle: if we plan regular releases, we might want to automatize it. If not, I have no problem with doing it manually.