Have CF+, or Lucee+ work to indicate an argument or feature that is only supported by a specific engine.

[mjhagen]

Would work the same way as CF9+ just without the version number.

[pfreitag]

That would be handy in some cases I think so I'm not opposed to adding that. I do prefer if the version number is included if possible since that is useful information in most cases.

[mjhagen]

I ran into one on directoryList, the type argument is only available on ACF, I wondered if I should add a note for Lucee/Railo/BD, or one for ACF and thought that just having a label on the argument itself would be clearer (right now I added CF9+ on that arg.)

[timbeadle]

👍 on this idea. Similar to the browser table on e.g. Mozilla Developer Network: https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Array/concat

[timbeadle]

(& I was tripped up by string.replaceList() not being implemented on Lucee 4.5)

[shaedrich]

Keep in mind that features can be removed (e. g. CF11-). Should it be releated to engines.minimum_version?

[KamasamaK]

An engines object would be good for this, but it would need to relate to each parameter instead of the entity as a whole. Also, @shaedrich brings up a good point. The engine object should also indicate when something was deprecated or removed, in addition to when it was introduced. Perhaps something like

"params": [
	{
		"name":"funcArgNameOrTagAttributeName",
		"description":"What it does",
		"required":true,
		"default":"false",
		"type":"boolean",
		"values":["true","false"],
		"engines": {
			"coldfusion": {"minimum_version":"10", "deprecated":"", "removed":"", "notes":"CF Specific Info Here"},
			"railo": {"minimum_version":"4.1", "deprecated":"", "removed":"", "notes":"Railo Specific Here"},
			"lucee": {"minimum_version":"4.5", "deprecated":"", "removed":"", "notes":"Lucee Specific Info Here"}
		}
	}
]

[shaedrich]

- could indicate a removed feature, but how about a deprecated one? (@KamasamaK good idea to add deprecations as well)

[shaedrich]

This should be done for values as well.

[pfreitag]

We currently have support for deprecated tags/functions in the engines key but not specific attributes / arguments. My preference for implementing this would be to replicate the sytanx used in the engines key and add it to the object in the params key.

[pfreitag]

It also supports features that have been removed... Here is an example of a tag that was deprecated in CF6 then removed in CF11 https://cfdocs.org/cfservletparam https://github.com/foundeo/cfdocs/edit/master/data/en/cfservletparam.json

"engines": {
	"coldfusion": {"minimum_version":"4.5","deprecated":"6", "removed":"11", "notes":"", "docs":"..."}		
}

[KamasamaK]

I did find that it supports deprecated and removed when looking at the code (I initially had named them deprecated_version and removed_version to match minimum_version), but missed them previously since they were not in the JSON File Documentation of the README. I would be fine with creating a proper JSON schema that could be referenced as well.

[shaedrich]

You are right. But why are the positions of deprecated and removed switched under syntax and compatibility?

To display deprecated and removed version number as alert boxes but minimum_version as label seems a bit inconsistend to me. I would suggest to change CF4.5+ to more clear CF4.5-11.

[pfreitag]

@shaedrich - no good reason they are switched, it probably makes sense to show removed first, then deprecated since. Also it would be good to show CF4.5-11

@KamasamaK - yeah need to add those to the docs... A JSON schema would be great!!!

[shaedrich]

Does the ci currently check more than just the validity in the JSON?

[pfreitag]

Yes the ci does do additional checks besides json validity, it checks that the result is correct in the examples. It also looks for a few required things in the JSON file, but having a proper JSON schema would be great because I could add that to the CI tests.