documentation best practices

[Dick Spierings]

Why can't you simply add a main section called "Future developments" or alike to your book(s) and sum up the future developments there (and add a reference to the current AS IS situation)?
That would not conflict with the actual AS IS content and still please the marketing request (cause that's what it is!) 

Vriendelijke groet / Kind regards,
 
Dick Spierings
User Documentation
 
 +31 (0)413 343786
  www.fluidwell.com
w d.spierings at fluidwell.com 

Date: Mon, 5 Dec 2011 02:56:00 -0800 (PST)
From: hessiansx4 <hessiansx4 at yahoo.com>
To: "framers at lists.frameusers.com" <framers at lists.frameusers.com>
Subject: documentation best practices
Message-ID:
	<1323082560.94393.YahooMailNeo at web114713.mail.gq1.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"

I could use some insight into a situation I haven't encountered before today: how does one best respond to a request (read: order) to include something in their product's documentation about a functionality that will not be released with the upcoming release?(it will?still be in development)?but is hoped to be ready "shortly" (whatever that means)?after the product is released.
?
I've politely pointed out that industry best practice is to document what IS as opposed to what WILL BE and that certain liabilities might be incurred if promises are made and then something goes wrong. 
?
Any thoughts?