i guess we can then provide a similar solution to @deprecated for @experimental ?

Also note that I don't want us to abuse this. It should only be used for big new features that are difficult to think of without some real-world usage.

I suppose "subsequent versions" does not include 2.3.x, but it might be worth specifying.

So, to make things clear with the security example; we have two options:

• include it as experimental in 2.3;
• wait for 2.4 to include it and gather feedback from user using the bleeding edge.

Personnally I would include it in the 2.3, specified as experimental, since it would allow to gather feedback before releasing the 2.4 and consequently to have a better final feature.

Can't we have a 2.3-experimental branch so that developers will not risk to use experimental features in their critical projects? The main problem is that we have to maintain 2 branches: 2.3 and 2.3-experimental.

Otherwise, why not creating a new SymfonyExperimentalBundle that contains all experimental features? If these features are approved by the community then we can move them from the bundle to the core in 2.4, 2.5... The main problem is how to deal with namespaces without breaking BC when moving everything to the core.

Or what about a symfony-experimental third party repository/package like we have for Twig extensions?

I don't think mixing experimental features in 2.3 is a good idea. Having a third party bundle/repository/package is probably better. This package will have to be explicitly added to the composer.json file by the developer if he wants to use experimental features.

It makes sense to add it as a third part bundle but if the goal is to have as many feedback as possible, you'll have to find a way to encourage web dev to use these features.

I do like @hhamon idea. We can have a symfony-experimental repository that mirror the namespace of the main symfony repository but where everything is prefixed with experimental like in Symfony\Bundle\SecurityBundle\Experimental\....

We can always advertise for installing a third party dependency that contains such experimental API in the documentation, blog post and even in the code with commented code.

The Experimental subnamespace is a good idea too. That way we're clearly aware of using experimental code. Then, when this code will be considered stable we will move it to the core by just removing the Experimental part of the namespace. Migrating the codebase in a project should be easy that way.

That being said, I'm not sure it is worth it (creating another repository). I don't expect using this experimental thing that often: the PR on security, perhaps the one about the request context. I don't have any other example for which we would have used this (perhaps the proxy thing too).

The Cache component that was discussed several months ago too?

I like this approach, it make sense to keep new feature out of core until they are ready. Merging early into core would discourage to make BC breaks on non final stuff.

I like the @hhamon approach that not mixed experimental features with stable features. If you want use experimental, you change your composer file.

2.3 should be considered completely stable, because it is a LTS. Developers and organizations seek this in this kind of releases. Please correct me if I'm wrong.

As a Symfony developer I agree with @jonsxaero , I want the main channel to be reliable. Having a separate repository for experimental features seems like a good choice.

I'm agree with @hhamon and @jonsxaero. Experimental features have not to be on 2.3 LTS

I disagree a bit with previous speakers, marking features experimental is a very explicit and good way to include unfinished functionality even in an LTS release. Python did this with import from __future__ for a long time and given the coupled release cycle of all the components to each other (no seperate releases), it would be near to impossible to experiment with APIs, which is often necessary.

Without something like experimental, new features have to become stable between any minor release (2.3 -> 2.4 etc). This is a timeframe much too small for some things.

@beberlei how would you do an equivalent of import from __future__ with Symfony in this case?

@hhamon just mark the API as @experimental as PHPs object model is too static to do much else. If its just new objects (compared to changing existing ones as well) one could think about adding something to the debug autoloader to prevent this, if not enabled.

All releases, except LTS, are good to include new features and experiment with them, but in my opinion LTS is focuses on stabilizing everything as we can and give a long support. I insist that stabilizing is a reason to take into account by developers and organizations to adopt this new release. Therefore, we should not mix stable and experimental features in 2.3. Maybe It's a good idea to create a separate experimental bundle.
sorry for my english.

What about modifying the autoloader slightly to try to load classes in an Experimental namespaces, so, if you try to load Symfony\HttpKernel\Kernel.php it will try to load Symfony\Experimental\HttpKernel\Kernel.php, if it doesn't exist, it falls back to Symfony\HttpKernel\Kernel.php.

You should be able to turn on and off this behaviour somehow.

@loalf That is hackery :-) and it violates PSR-0, breaking composer and such

@beberlei you expect this kind of things from experimental stuff, no? ;) Yeah, you are right, discard it.

What about cases where experimental features break BC of existing functionality? Are we talking here of only new features which don't change the existing API?

@experimental seems immediately intuitive. It would make testing experimental features dead easy. I would like to see some tool support that can warns against @experimental the same way as for @deprecrated, though.

@gunnarlium the problem with @experimental is that most developers won't pay attention about it and they will use experimental features without being aware of it. That's quite risky in my opinion.

What will be the commitment of an experimental feature in 2.3 LTS? Are you going to backport any changes made in subsequent versions if something changes?

I think given that experimental means that there is no guarantee of stability of the code, that it should have to be specifically imported from somewhere else (another repository or namespace like Symfony\Experimental) means that the developer has to make a conscious decision to opt into unstable code in a stable branch.

I agree with @hhamon. Most devs will rely on IDE autocompletion and won't even notice the @experimental tag. IMHO, from a user point of view, a separate branch/repository is the safest solution.

This is impossible for code that extends existing classes.

Preventing accidental use of experimental code could be done in the Debug autoloader (just for dev mode): https://gist.github.com/beberlei/1ee7d78c181ca1abf796

But this would still require some mechanism for collaborators to check if experimental is enabled or not. So its not perfect

It looks quite hacky for me.

If I may compare this problem to the car industry, I would say that when you buy a car, you buy a car ready for production use. You don't buy a car that has experimental airbags. This is for your own safety.

My opinion is that it should be the same for Symfony. The 2.3 branch should just contain the stable API which is safe. If you want to live on the bleeding edge you have to install a 3rd party package that provides the non stable API.

No need to create yet another repository for experimental features as it would be only interesting for big ones (and we don't have that many of them). I prefer to wait for the next version to include these features.

Thanks for your comments.