Switch to ArdorForum

Of course NXT must stay backwards compatible. A few more methods to maintain in the classes, how is this a problem?

Quote from: Jean-Luc on November 06, 2015, 08:44:04 am

The 1.6.1e changelog did have an "incompatible changes" section, and the rest of the incompatible changes were also included in the 1.6.2 changelog, but now we realize that in practice this is not sufficient. To improve communication to potentially affected parties, we plan to setup mailing lists for such notifications, and make sure to announce important changes as early as pratically possible in the future.

If I remember well, last year, after "first crisis" due to incompatible changes of API in core NRS, there was a promise/assumption "to create a mailing list for such notifications". To make a mailing list is really-not-to-hard-action, that spends 15-20 minutes at all. So, question is simple -- why it cannot be done for whole the one year and now we're there again -- in the same situation ?

In any case, I'd like to believe that this is a huge lesson for "both sides", or for the all participants, more precisely. Also I hope very strong, that James will be able (and wants to do it) reconsider his decision. Partnership between SuperNet and NXT is extremely interesting and important, and - as James mentioned - it's probably more important for NXT and it's "living condition". A moment before 2nd anniversary of NXT, we have lot of serious troubles anyway - marketcap is on 1/10th as before (well, doesn't matter too much), user interest is probably smaller than earlier (this is much worse), still (almost) no success with any marketing steps (hopefully Tennessee would change it). Under this situation, leaving of SuperNet would be - I'm afraid - the "kiss of death".

But maybe we still can find a consensus, hopefully. It would be the last chance for it.

We are putting up that mailing list right now. And yes, it's needed.

What is also needed is that we listen to each other (this goes for both sides of the fence!).
This is starting to turn into an entrenched warfare and that doesn't help anyone.

There needs to be a basis of trust for this, so let's not destroy that by being intransigent.

This is a trust issue we are facing, apart from the API.

To me, thát is what needs to be addressed.

To me it is clear that if this version breaks the API, you should revert it.

In the current environment Nxt is in, a change in the API could make many services permanently broken, and many of them will not be updated. Maybe some software companies can force their clients to upgrade, but not Nxt in the current situation with the falling market price.  Services that use Nxt and notice it has stopped working would just disable it.

Shepeshift already stopped, and coinomat in supernet lite client also has problems.

Quote from: martismartis on November 06, 2015, 05:12:25 pm

Quote from: v39453 on November 06, 2015, 05:09:23 pm

To me it is clear that if this version breaks the API, you should revert it.

In the current environment Nxt is in, a change in the API could make many services permanently broken, and many of them will not be updated. Maybe some software companies can force their clients to upgrade, but not Nxt in the current situation with the falling market price.  Services that use Nxt and notice it has stopped working would just disable it.

Shepeshift already stopped, and coinomat in supernet lite client also has problems.

Are exchanges affected?

It is very probable that especially Exchanges that use Assets (like Poloniex) will get problems as soon as they update. So I would recommend them not to upgrade or closely watch and integrate the changes when updating. This includes all cronjobs or scripts checking for regular incoming payments, everything that relates to display of holdings and previous transaction history.

There will be no reversal in 1.6.3.

I am very sorry to hear this.

I hope you will reconsider as without a fixed 1.6.3, I will be forced to minimize SuperNET's reliance on NXT to protect the installed based from one day just having things broken. With the lite nodes being popular and using the public nodes, this is not something that can be controlled.

You dont seem to understand that it is impossible to anticipate future changes in existing API and also that it is impossible to get the already installed software on the decentralized nodes to be updated prior to any such event. Even with notification, without months of deprecation period it prevents using NXT as a platform.

Would you respect the community's vote on this issue of backward compatibility?
I estimate it would take very little time to revert to the old default settings and that would fix dozens of API that were broken with the 1.6

James

Quote from: martismartis on November 06, 2015, 05:12:25 pm

Quote from: v39453 on November 06, 2015, 05:09:23 pm

To me it is clear that if this version breaks the API, you should revert it.

In the current environment Nxt is in, a change in the API could make many services permanently broken, and many of them will not be updated. Maybe some software companies can force their clients to upgrade, but not Nxt in the current situation with the falling market price.  Services that use Nxt and notice it has stopped working would just disable it.

Shepeshift already stopped, and coinomat in supernet lite client also has problems.

Are exchanges affected?

With dozens of API behavior changed, odds are the vast majority of anything that uses NXT is broken now.

This is why I have been making such noise about this. What are the chances that all the exchanges using NXT will make custom changes to previously working code in their main exchange software?

It might take them weeks to get it updated, tested and requalified. This is why a security attack vector is the ONLY acceptable reason to break backward compatibility. It is the ENTIRE installed base that could break in unpredictable ways

James

Quote from: Tosch110 on November 06, 2015, 03:24:15 pm

The problem is that SuperNET apps are mostly designed to use Jay. And what Jay does is that it connects to random public nodes (to increase decentralization and the user would not have to install Nxt locally and download the blockchain. Even though, we still open the possibility and recommend the user to install Nxt). What Jay will do most of the time when a user runs SuperNET Lite for example is connecting to strong nodes in the network. And these strong and reliable nodes are expected to run the newest stable version. So once this newest stable version (like 1.6.2) breaks the existing API, all SuperNET apps will not function in this case.

This explains a lot and also means that you cannot compare this situation to other centralized APIs.

This is once again a situation where we are the first to deal with, from decentralized development and deployment to actual usage of the system.

The other issue is the rapid development of NRS features, it's hard to remain stable if you are adding new features and reworking the internal structure very often.

Only solution I can see right now to solve this for the good on both sides is API versioning.

Yeah, it's good to be making history, though I'd prefer to do it a bit more quietly.

The above point on SuperNET (via Jay) connecting to random public nodes is important: this allows a short term workaround by only using 1.5.15 nodes, of which there are still about 100 running. This could also help other projects who may have issues with 1.6.3. 
Having a blockchain download available for 1.5.15 would be useful, btw.

For a long term solution, we need to raise our project management game, and by we I mean mostly Nxt.
James is right: people need to be able to completely trust that Nxt will provide a stable basis for their projects. If we lose that trust, Nxt will be just another crapcoin, because no-one will build on the Nxt platform.
However, we cannot maintain backwards compatibility indefinitely. Nxt needs to advance and evolve, otherwise we become a dead system.

What we now need to do is to create a project management structure that will maintain that trust, while allowing Nxt to evolve.
The first steps were taken last week, by appointing Riker to the project manager position, and starting with set-up of a communication channel for all Nxt/SuperNET related project devs and the core Nxt devs, so we were already getting a structure in place to avoid this. Slightly late, though.

Myself and Damelon are working out little asses off to get this sorted out with everyone concerned, so I'd like to ask the community to chill out for a few hours, and allow us to figure out  a long term solution.

In the meantime: as an immediate solution (if needed) advise projects to roll back to 1.5.15, and maybe some node operators could do the same.

strong agreement to link removal.

luckily I am a bit sloppy and sitll have 1.5.15 lying around, which is just now updating its blockchain

Alright, installing 1.5.15 again now...

same here!

Hold on.....project operators, and public nodes with open API are probably better off on 1.5.15, but ordinary end-users should stay on 1.6.2.