I agree. I think 3 is my preferred option; I think it lends itself best to a sustainable and straightforward workflow.
Docs fixes relevant to the current release of the CLI and each platform can be committed directly to master. Unreleased changes can be committed to the appropriate branch, and we can add the merging of the branch as a step in the release process. On Mon, Jul 14, 2014 at 1:06 PM, Ray Camden <rayca...@adobe.com> wrote: > Personally I'd rather not have any "coming soon" paragraphs in the doc > text. As a user, if I'm at the docs, I don't care what is coming next. I'm > trying to solve a problem I have *now*, or trying to build now. Anything > that is coming soon is a distractor. > > Do I feel strongly about it? No, but I'd vote against it being in the docs > at all. Stuff like that should definitely be communicated to users - via > the Cordova blog perhaps - but not in the mainline docs. > > ________________________________________ > From: m...@google.com <m...@google.com> on behalf of Max Woghiren < > m...@chromium.org> > Sent: Monday, July 14, 2014 10:27 AM > To: dev > Subject: Re: Pointing docs to edge > > Okay, so here are the current proposals for handling Ray's issue (thanks > Ray!): > > 1. Update docs at commit-time and release-time. At commit-time, > documentation changes can be marked with "coming soon", or "removed in next > release", or whatever the relevant message is. At release-time, docs are > further updated to remove these sub-messages. > > 2. Use CSS to do the manual marking in proposal 1. We could also use it to >
