Release 1.0

[m6w6]

So much code already depends on fast-route, how about making a commitment and release 1.0?

[nikic]

That seems reasonable.

Does anyone have any BC breaks they'd like to see before that happens? I don't really want to do a large API overhaul, but it would probably be a good idea to at least switch the dispatcher result to an associative array, so that the possible return values are

['type' => NOT_FOUND]
['type' => METHOD_NOT_ALLOWED, 'allowedMethods' => [...]]
['type' => FOUND, 'handler' => ..., 'vars => [...]]

or similar, rather than the current numeric indices.

[andersonamuller]

Why not return a value object?

[Potherca]

Does anyone have any BC breaks they'd like to see before that happens?

Issue #59 seems a prime candidate.

On a side-note, it might be useful to create a milestone or label for v2 and tag relevant tickets.
This would make it clear which issues have beens elected for v2 and allow people to contribute...

[m6w6]

This issue doesn't quite take the direction I actually had in mind. ;)

Because there's already so much code which depends on fast-route, I was rather thinking to release the current state of things as 1.0 and if there are desired changes with even BC breaks planned, those should be geared towards a v2.

Remember, version numbers are cheap. Thoughts?

[Potherca]

Sounds like a very solid plan.

Releasing a stable v1 with the the state the package is currently in would also make it trivial to fix and release any bugs that might pop up before v2 is fully complete (you never know).

I've taken the liberty of updating my previous comment to reflect the "Label a v1 now, create a v2 later" idea.

[nikic]

Sorry, forgot about this. I've just tagged v1.0.0 (https://github.com/nikic/FastRoute/releases/tag/v1.0.0) which is identical to v0.8.0 as far as code is concerned.