On Apr 29, 2014, at 11:14 PM, Andrew Grieve <[email protected]> wrote:
>> I say we aim to make 3.5.0 our last cadence release. I'm hoping to switch
>> to independent platform releases.
>>
>> As for docs, I don't think everyone is convinced yet that loosing the
>> version numbers is the way to go. I say we add version 3.5.0 to docs and
>> then make the switch to edge for the next cli release. That way it fits
>> well with this being our last cadence release.
>>
> Haven't seen any opposition to this on the list or in your doc. Might as
> well go to edge now, no?
I like Steve's idea to make the switch to edge at the first post-cadence
release.
For losing the version numbers in the docs, I can see how something like a
"@since" tag could help, but that is really just for new APIs. If there is a
behavioral change or return value change, how does that get documented? Are we
talking something like:
globalization.getLocale() returns:
symbolic name, i.e. "English" (before r1.0.0)
BCP-147 identifier, ie "En_US" (since r1.0.0)
For this reason, I'm not yet sold on the non-creation of versions in the docs.
Thinking out loud: For plugins, the docs are now in each plugin repo. We could
continue to create versions there, or link to github with a tag/branch name to
render as HTML. I think the latter would be sufficient and easy. But to do this
right, the same thing ought to happen with platforms and tools. Then it becomes
consistent across all our repos, and the same approach can be used for
versioning the docs. The only thing in cordova-docs would be overviews. Is this
idea loathed?
On a slightly different topic: So what identifier are we using to specify a
point in the timeline of all these independent releases (platforms, plugins,
tools)? The goal is to have a recreatable state of Cordova. Is it the CLI
version because that gets bumped for every component release?
