missing for stable release

[dbu]

lets collect what remains to be done and discuss here whether things must be in 1.0.0 or not. lets create issues for concrete tasks and reference them, and put them into https://github.com/php-http/HttplugBundle/milestones/1.0.0 if we think we need them.

[dbu]

imo #26 can also be done after 1.0 is released. we can improve the toolbar even as patch release i think.

[Nyholm]

In my opinion we should ask ourselves when to release a stable release. A bundle is kind of different from a a library.

We could release when we are sure we do not break BC. Or we could release when we are somewhat feature complete and are not under heavy development.

In terms of BC. What are our BC promise for this bundle? It does not have any public classes so our BC promise is just config? (Am I correct?)

In either way we need to add tests and make sure it works on Travis with all the supported Symfony versions.

[dbu]

i think we should not aim for feature completeness. the bundle can already do useful things, and people starting to use httplug in symfony should be able to use a bundle rather than define their own things (thus re-inventing the bundle).

i think indeed the BC is for the configuration, so we need to be sure it makes sense and have enough tests to detect when doing non-BC changes to the configuration.

and we should have some tests to know things work on all versions of symfony we claim to support. thought that looks ok except for https://github.com/php-http/HttplugBundle/blob/master/.travis.yml#L33 => we should not allow the lowest build to fail, that is strange.

[dbu]

with #52 done, is there anything that prevents us from tagging a stable release?

[Nyholm]

Like said before: Our BC promise is our configuration. PR #44 made a BC breaking change. Are we happy with how the configuration looks now?

I think we need to document the bundle properly before we make a release. The current documentation is just a bunch of unstructured examples (yes, mostly my fault). I do also believe that we might find some quirks while organising the documentation that maybe should be resolved before tagging 1.0.

I do also think we should fix #14 before 1.0.

[sagikazarmark]

I would also do as explained in #40, even if we don't wait for a stable release of Puli.

[Nyholm]

I just come to think about this: We should not do a stable release while we have dependencies that are not stable. If that is Puli or our own discovery package does not matter.

[sagikazarmark]

@Nyholm see @dbu's comment regarding this in #40

[Nyholm]

Yeah, I know. I was kind of answering that comment here to keep the "When to release 1.0"-discussion in this thread instead.
I would be happy to release 1.0 now and then improve the discovery layer later when Puli is stable (this summer? fall? Christmas?). But php-http/discovery should be tagged 1.0 before we can tag 1.0 of php-http/httplug-bundle.

[sagikazarmark]

As I stated in that issue as well, we should remove the discovery package usage from the bundle entirely and use only Puli. If you take a look at the discovery package now, it is mainly a static wrapper around Puli. However, Puli provides discovery as a service in its bundle. So I propose getting rid of the static stuff and use Puli bundle and discovery service in this bundle directly. Expect a PR tommorrow.

[Nyholm]

Cool, but that does not solve the problem with non-stable dependencies. If we remove dependency on php-http/discovery and replace it with puli/symfony-bundle we would still have to wait until it becomes stable before we can tag 1.0.

We could, however, remove php-http/discovery and then make puli/symfony-bundle optional. That would allow us to tag 1.0 since we no longer have unstable dependencies.

[sagikazarmark]

No, it does not solve the stability question, but we don't have to tag discovery 1.0 that way.

And we cannot make puli bundle optional since the service is necessary. Container compilation will fail otherwise. But I don't think making it a dependency is a problem: it does not require the composer plugin and based on what's inside the bundle, it is very unlikely that any BC incompatible change will happen with it. So I don't see an issue in relying on it in our stable version.

[Nyholm]

No, it does not solve the stability question, but we don't have to tag discovery 1.0 that way.

That's right. We can do 0.x versions until all our dependencies are stable.

And we cannot make puli bundle optional since the service is necessary. Container compilation will fail otherwise.

Im not sure this is correct. You can configure HttplugBundle to not use Puli or any discovery.

I believe it is a good idea to not require puli/symfony-bundle and check in our container extension class if discovery is needed and if so verify if puli/symfony-bundle (or Puli) exists.