Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] Discuss path for updating doc params, syntax for different versions #31

Closed
melinite opened this issue Feb 23, 2014 · 8 comments

Comments

@melinite
Copy link

Need a plan of attack for how best to display version specific syntax, attributes, etc.
CF11/Railo and beyond will most likely enhance tags/functions that will either break or silently ignore.


We could:

  • display version support by tabs or pillboxes (All Latest ACF Railo OpenBD)
  • add extra column/field for version support since (paramSupportedSince...)
  • or just not worry about it. Let developer deal with it.


I have updates for the CFDoc JSON Builder to be able to load a tag/function json and edit.

@pfreitag
Copy link
Member

My thought was to keep it simple initially. So ideally if there are any compatibility differences those should be put in the notes field under each engine. If that doesn't end up work well, then we could add a compatibility column to the params struct, but I'd like to avoid that until it seams necessary.

@pfreitag
Copy link
Member

The more I think about this, it might be a good idea to have support in the params for compatibility info -- I am thinking something like this:

params: [ { compatibility: { engine: "coldfusion", version: "11", notes: "Added this attribute" }, ... } ]

What do you think.

@melinite
Copy link
Author

looks good. So dropping the min version in the primary attribute of a parameter and utilizing the version inside the compatibility key?

@pfreitag
Copy link
Member

Was there a min version attribute in params? If so I don't know if it was used anywhere.

There is a minimum_version in the engines key -- which I think I'd like to keep that because I am using that to show the version number in the anchor text to the official docs on the top right.

@melinite
Copy link
Author

You're right i don't think there was a min version params. I was thinking about engine.

@sihu
Copy link
Contributor

sihu commented Aug 1, 2014

Just as a short addition: Adobe has a history for each tag with all attribute-changes in their documentation (e.g. Coldfusion 9 - cfdump) but i like your suggestion and think, it would be more flexible. As a next step you could summarize all changes of all attributes and display them in as well in the end.
might be that it would be useful to know, when the tag was added to the language (the min-version), but as showed in cfdump, some attributes were added or changed later, so it would be nice, if that was also visible.

@pfreitag
Copy link
Member

pfreitag commented Aug 4, 2014

Sihu - there is the ability to specify what version that the tag was added under the engines key, see example here for a function that was added in cf10 and railo 4: https://github.com/foundeo/cfdocs/blob/master/data/en/sessionrotate.json then when you look at the doc page it shows R4+ and CF10+ on the top right, and links to their respective documentation. Under the engine key you can also specify notes which list any compatibility notes for a specific engine, you could use this to list history of new attributes but I think adding it to the params is going to be a better more structured approach in general, but since we don't support that yet if you want to add something to the notes or the description of the param feel free.

@pfreitag
Copy link
Member

pfreitag commented Jul 8, 2015

I'm going to close this, I think we can simply add CF9+ in the param description if necessary, I don't want to make it too complicated.

@pfreitag pfreitag closed this as completed Jul 8, 2015
pfreitag pushed a commit that referenced this issue Nov 13, 2018
Replace "Fork me" image with css styled span
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants