I would prefer to have the 'coming soon' stuff more visible. I like the idea that when looking for how to do something, its easy to see improvements that have already landed - and I can possibly get just by grabbing a bleeding edge plugin/tool.
On Mon, Jul 14, 2014 at 1:25 PM, Max Woghiren <m...@chromium.org> wrote: > 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 > > >
