Mandatory upgrade to NRS 1.7 before 21 Jan 2016

I'm currently sending the following message out to all exchanges to help them with the upgrade path from 1.5.15 to 1.6.2 to 1.7.There's useful information here for everyone,if you run an NXT-based project.Spread the word.....*************************************************************************************************The next planned Nxt release,will be a mandatory upgrade for everyone, as it will be a hard fork.The first 1.7 version will be released at the end of this month (November 2015) as an experimental release,a stable mainnet 1.7 version will be released at the end of the year,and the 1.7 hardfork will be set to occur in mid January 2016.Any systems still running on versions older than 1.7 will be adversely affected.We recommend that any systems still running now on the last version (1.5.15) be upgraded as soon as possible to the newest stable release: 1.6.2.This will make the transition to the 1.7 branch much simpler.(Note: this does not apply to MGW node operators, liase with the MGW team for the latest information), and we will be unable to provide effective support for that upgrade path.While the stable 1.7 version has not been released yet, it isimperative for Nxt-based projects that preparations for migration to 1.7 begin now, as for anyAPI client this will involve a number of code changes. The current stable release is 1.6.2,and all API changes required for 1.7 are already fully supported in 1.6.2.will ensure a smooth transition to 1.7 when it is released, as there should be no APIincompatibilities between 1.6.2 and 1.7 stable.Below is a high level review of the code modifications required.A detailed list of all affected APIs is posted at: https://nxtforum.org/nrs-releases/nrs-v1-6-2/msg199198/#msg199198 , andthe changes are also discussed in the 1.6.0e, 1.6.1e, and 1.6.2changelogs, available as usual in the changelogs directory of the 1.6.2release package. Please do read the information in these changelogs.1., which in 1.5.15 and previous releases returnadditional information, at a performance cost, have had their defaultsmodified not to return those extra fields unless specificallyrequested. The format of the API response has not changed, only whatfields are returned by default. If your code uses any of those APIs andin some invocations needs the additional fields, make sure to add thecorresponding "include" parameters in those places.2. TheandAPIs,deprecated in 1.5 have been removed in 1.6. UsegetBlockchainTransactions instead and make sure to handle correctly thephased transactions. Some enhancements to getBlockchainTransactions,such as being able to get only executed phased (or not phased)transactions, introduced in 1.6.1e, should make that easier.3. Some APIs no longer do aof the user input.Any APIs that accept an object id such as account, asset, or currency,but do not need to retrieve the actual object, no longer check for itsexistence. Such APIs will now return an empty result list instead of anerror, when supplied for example with non-existent asset id.4.are now treated as deletionof asset shares, and as such are not retrievable using thegetAssetTransfers API. The quantityQNT in the asset JSON returned byAPIs such as getAsset now corrects for such share deletion. Theoriginal asset quantity issued is returned as initialQuantityQNT in theasset JSON.The above API incompatibilities must be taken care of on upgrade from1.5.15 to 1.6.2. The 1.7 API will be consistent with 1.6.2 and willrequire no further adjustments.Other than the API tweaks, there are two major changes to take effectin the 1.7 hardfork, that require taking action now and preparing inadvance:1. For virtually all transaction types in 1.7,(currently 1 NXT), but based on the actualtransaction size. As it is not possible to hardcode the logic for feecalculation in each client of the API, the approach suggested is to letthe server determine and use the minimum fee required, which happenswhen a new transaction is submitted with feeNQT=0 parameter. Thisfeature is fully supported in 1.6.2, and therefore a migration to usingserver-side calculated fees can be started now.2. The(plain orencrypted) has been significantly reduced, from 1000 bytes to 160bytes. If you use permanent messages, regardless of the transactiontype they are attached to, you need to make sure their size does notexceed 160 bytes. As fees for permanent messages have also beenincreased significantly and are proportional to the actual messagesize, it is strongly recommended to switch to using prunable messagesinstead. To create a message as prunable, the only change required isto add messageIsPrunable=true parameter to the correspondingtransaction creation API call. The format of the transaction JSON isthe same for permanent and prunable messages (this is why they can'tboth coexist in the same transaction), therefore no changes in parsingthe JSON response are needed. Prunable messages are also deleted bydefault after 90 days. If your application needs to have them availablelonger, or indefinitely, this can be configured in the nxt.propertiesfile, and it is also possible to automatically retrieve such expiredprunable messages from archival nodes running on the Nxt network.Prunable messages have been supported since 1.5, and archival nodes areintroduced in 1.6.2, so again the migration from permanent to prunablemessages can be started now, without waiting for the 1.7 stable release.Please see this forum thread for information and discussions regardingthe transition to prunable messages and the fee calculation changes:We have also set up a, to allow better direct communication with the Nxt dev team, so if youare responsible for an Nxt-based project, sign up here:**********************************************************************************************