studio

studio copied to clipboard

See https://groups.google.com/forum/#!searchin/thephpleague/architect/thephpleague/f0ynLoxRpvQ/dTBz3Zi8bAUJ

Thanks for considering, I'm generally open for moving to the league. =)

Can you tell me a little more about what this would entail?

Moving stuff to the League is all about helping you to make a singular library even better. We all chip in to make sure the library stays alive, and that pull requests and issues don't go unanswered. When you need to take a break/go on a holiday/whatever, then we help with things.

There are a few code/repository requirements; like setting up CI and having a level of test coverage. I'll submit pull request(s) for much of the code-related stuff, but a significant code change is that League packages have League as the vendor (in namespaces).

:+1:

Moving to the League would provide more exposure, which is a good thing.

Don't let "the League" steal your glory. You built this.

@swt83 that's a tad dramatic. Its not a change of ownership, it's a promotional platform and support network.

+1 for this, it's a hidden gem that would definitely get much much more exposure being part of League

Thanks for the kind words, @spamoom. :+1:

Once I finish my master thesis (about a month to go), I'll follow up on this. :)

Happy to help if I can!

@assertchris Still interested in this?

I achieved a major breakthrough for the next (major-ish) version yesterday, by getting my PR merged into Composer. Studio now does something much less hack-ish, but far more magical, by dynamically generating Composer path repositories, all without touching the composer.json file. This means, package maintainers can benefit from this kind of setup without having to change anything in the files managed by Git.

In any case, how would we proceed? I'm about to release an 1.0 version, would the move to the League need to happen before doing so?

Hey @franzliedke. I'd love to work on this but right now I have negative time to. The move to league doesn't have to happen before you tag 1.0, but it will be a breaking change (major version bump, according to semver) when it does happen.

I wonder how important BC is for such a package, since it's not a library, but rather a tool to be installed globally using Composer (even if it's installed only for a project, it's only the bin/studio file that people interact with).

@franzliedke Is the new version testable yet ?

Weeeeelll... the code is object-oriented. So it is testable, but not tested.

Also, most of it is in console commands, where I didn't know how to best test those. Any clues? Feel free to open an issue about that.

Oh I actually meant 'real-life' testable, with the last version of composer.

Oh that, yes, please test it out. Make sure Composer is up-to-date (a version from today or yesterday) and use Studio's latest dev-master. It works well for me and my large Flarum dev setup.

Moving a library like this to League (or another Foundation) often helps to keep it alive, even when the original maintainer does not want to work on it further. But it's no guarantee. I have seen tiny projects fail, because nobody at a Foundation felt responsible (or had the time).

It would be the first project of this toolish kind. Might not mean anything.

Personally I like many league packages. Not all of them.

You would have some "community" which gives you a framework. This can be good or bad.

The other way would be to try build a community around Studio itself. I think it is hard, because I believe Studio should be a part of the Composer project itself, and the features should be available natively in Composer.

Whatever you do, keep up the great work. I will certainly follow.