cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: 3.5.0rc1
Date Wed, 30 Apr 2014 15:38:50 GMT
On Wed, Apr 30, 2014 at 11:08 AM, Marcel Kinard <cmarcelk@gmail.com> wrote:

>
> On Apr 29, 2014, at 11:14 PM, Andrew Grieve <agrieve@chromium.org> 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?
>

Having plugin docs versioned with the plugin is definitely the idea. Only
guides & specs will remain in docs.cordova.io.
For changes in CLI / guides, then we should call out when features were
added right inline in the docs.

For the events APIs, I think the button events should be moved into a
plugin. That would leave only deviceready, pause, resume.


>
> 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?


We don't actually have this right now since plugins are uncoupled. If you
wanted right now to take the release version of everything and tag it, I
think you'd be fine to just use a timestamp as the label.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message