think that sort of thing belongs to a preview blog post written by the person promising it will land not our canonical docs
On Mon, Jul 14, 2014 at 10:30 AM, David Kemp <drk...@chromium.org> wrote: > 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 > > > > > >
