Open NateEag opened 3 years ago
The v2.x branch is pretty much dead. It doesn't receive any support and is not being maintained for the last couple of years. Adding OPTIONS
to RAML 1.0 (master
branch or against the latest v4 release tag) will be however more than welcome.
Please note that master
is getting prepared to drop all EOL PHP versions, so if you are targeting support for PHP <7.3 branching from one the v4 release tags will be necessary.
It looks to me like OPTIONS
is already supported in master.
I haven't tested that or looked at the 1.0 branch beyond that observation, precisely because of the dependency on PHP >= 7.3. As you seem to have guessed, the project I'm dealing with is still on an older PHP.
Thanks very much for the info.
Sounds like you can switch to v4.7.0 as it provides support of PHP 5.6. I'm afraid you'll have to fork and cherry-pick any changes that will give you support for PHP versions before 5.6.
This project is on PHP 7.0, so that should work fine. Thanks for the tip!
Do you happen to know if there are backwards-incompatible changes between the v2.x branch and the v4 line of development?
I don't see a changelog or a declaration of version numbering methodology, hence the question.
If you don't know offhand, no worries - just figured it was worth asking.
There should be several backwards-incompatible changes but I can't name them as most of that work was released before I joined as maintainer.
Okay, no worries. Thanks for the info!
I've got a project that still contains the original alecsammons version of this library.
I discovered recently that it does not support the
OPTIONS
HTTP method in RAML documents, which I have a use for in this project.It looks like
OPTIONS
is still unsupported in thev2.x
branch.The RAML 0.8 spec says that methods must be one of the HTTP methods defined in HTTP 1.1 by RFCs 2616 and 5789.
RFC 2616 defines the
OPTIONS
method.Would a PR adding
OPTIONS
support to thev2.x
branch be accepted?