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,
especially if you run an NXT-based project.
Spread the word.....
*************************************************************************************************
Mandatory upgrade to NRS 1.7 before 21 Jan 2016The next planned Nxt release,
1.7, 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)
An upgrade from 1.5.15 to 1.7 is NOT recommended, 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 is
imperative for Nxt-based projects that preparations for migration to 1.7 begin now, as for any
API 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.
Upgrading to 1.6.2 now will ensure a smooth transition to 1.7 when it is released, as there should be no API
incompatibilities 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 , and
the changes are also discussed in the 1.6.0e, 1.6.1e, and 1.6.2
changelogs, available as usual in the changelogs directory of the 1.6.2
release package. Please do read the information in these changelogs.
https://nxtforum.org/nrs-releases/nrs-v1-6-2/https://nxtforum.org/nrs-releases/nrs-v1-6-1e/https://nxtforum.org/nrs-releases/nrs-v1-6-0e/1.
A number of API calls, which in 1.5.15 and previous releases return
additional information, at a performance cost, have had their defaults
modified not to return those extra fields unless specifically
requested. The format of the API response has not changed, only what
fields are returned by default. If your code uses any of those APIs and
in some invocations needs the additional fields, make sure to add the
corresponding "include" parameters in those places.
2. The
getAccountTransactions and
getAccountTransactionIDs APIs,
deprecated in 1.5 have been removed in 1.6. Use
getBlockchainTransactions instead and make sure to handle correctly the
phased 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 a
detailed error checking of 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 its
existence. Such APIs will now return an empty result list instead of an
error, when supplied for example with non-existent asset id.
4.
Asset transfers to the Genesis account are now treated as deletion
of asset shares, and as such are not retrievable using the
getAssetTransfers API. The quantityQNT in the asset JSON returned by
APIs such as getAsset now corrects for such share deletion. The
original asset quantity issued is returned as initialQuantityQNT in the
asset JSON.
The above API incompatibilities must be taken care of on upgrade from
1.5.15 to 1.6.2. The 1.7 API will be consistent with 1.6.2 and will
require no further adjustments.
Other than the API tweaks, there are two major changes to take effect
in the 1.7 hardfork, that require taking action now and preparing in
advance:
1. For virtually all transaction types in 1.7,
fees charged will no
longer be constant (currently 1 NXT), but based on the actual
transaction size. As it is not possible to hardcode the logic for fee
calculation in each client of the API, the approach suggested is to let
the server determine and use the minimum fee required, which happens
when a new transaction is submitted with feeNQT=0 parameter. This
feature is fully supported in 1.6.2, and therefore a migration to using
server-side calculated fees can be started now.
2. The
maximum allowed size of permanent message attachments (plain or
encrypted) has been significantly reduced, from 1000 bytes to 160
bytes. If you use permanent messages, regardless of the transaction
type they are attached to, you need to make sure their size does not
exceed 160 bytes. As fees for permanent messages have also been
increased significantly and are proportional to the actual message
size, it is strongly recommended to switch to using prunable messages
instead. To create a message as prunable, the only change required is
to add messageIsPrunable=true parameter to the corresponding
transaction creation API call. The format of the transaction JSON is
the same for permanent and prunable messages (this is why they can't
both coexist in the same transaction), therefore no changes in parsing
the JSON response are needed. Prunable messages are also deleted by
default after 90 days. If your application needs to have them available
longer, or indefinitely, this can be configured in the nxt.properties
file, and it is also possible to automatically retrieve such expired
prunable messages from archival nodes running on the Nxt network.
Prunable messages have been supported since 1.5, and archival nodes are
introduced in 1.6.2, so again the migration from permanent to prunable
messages can be started now, without waiting for the 1.7 stable release.
Please see this forum thread for information and discussions regarding
the transition to prunable messages and the fee calculation changes:
https://nxtforum.org/core-development-discussion/adapting-client-side-code-to-the-fee-changes-planned-for-1-7/We have also set up a
mailing list, to allow better direct communication with the Nxt dev team, so if you
are responsible for an Nxt-based project, sign up here:
http://nxt.org/cgi-bin/mailman/listinfo/nrs-development **********************************************************************************************
