Is 0.4.0 shipped yet?

[jbenet]

This issue is here so people can subscribe and be notified when they should upgrade. This is important because of the network breaking change.

[lgierth]

To answer the question: not yet.

:)

[RichardLitt]

Can't wait!

[Mithgol]

https://github.com/notifications → https://github.com/notifications/participating

[jonnor]

What is the status? Last release seems to be 0.4.0-rc2 20 days ago. And seemingly there are features going into master since then?

[RichardLitt]

Ping @whyrusleeping

[whyrusleeping]

we're just waiting on our new integration test suites to run for a little bit to ensure things are all working smoothly before shipping.

[whyrusleeping]

Alright, heres my checklist for shipping 0.4.0:

• write changelog (@whyrusleeping @lgierth @RichardLitt)
  • see #2459
• finish blog post (@RichardLitt)
• add final 0.4.0 build to dist.ipfs.io and adjust 'latest' version ( @whyrusleeping or @dignifiedquire )
  • test that ipfs update shows the 0.4.0 update and can pull/install correctly ( @chriscool @whyrusleeping)
• ????? ( @jbenet)
• profit (@ipfs)

[dignifiedquire]

• Prepare new webui release @dignifiedquire
  • Merge feat/files-api on js-ipfs-api and release new version
  • Update dependencies on webui#master
  • Ensure geoip works on webui
  • Make release and upload it
  • Get at least three people to test it

[dignifiedquire]

First webui version to test: http://localhost:5001/ipfs/QmWCJFK5VYXBZqS3LbiRHt8aC3aLSVXU7wNFX9vpckSYun

For testing this run your daemon with ipfs daemon --unrestricted-api

[diasdavid]

Webui testing

• some errors:
• my browser froze on the logs tab
• shows type as ? but I'm pretty sure that the second is a dir and the first one is a file (but empty one)
• what about changing the "GO" button to "RESOLVE"? Kind of feel that it is a good opportunity to 'educate' our users that is what happens when a HASH is searched
• Other than this, looks pretty snappy and fast (I've tested it on a fast machine though), great work!!

[dignifiedquire]

shows type as ? but I'm pretty sure that the second is a dir and the first one is a file (but empty one)

This hasn't work for some time now (0.3.11, 0.3.10) and this view is going to be removed soon, so I'm not very concerned about fixing this.

what about changing the "GO" button to "RESOLVE"? Kind of feel that it is a good opportunity to 'educate' our users that is what happens when a HASH is searched image

This release is about making it work with 0.4, I know there are things we want to improve, but that's what the other work we are doing is for.

my browser froze on the logs tab

Logs are simply too much at the moment, we could remove them for now until we have a better solution, thoughts?

[dignifiedquire]

Fixed locales and minification: QmdmpbMUS1gJ3HppHxFjkUWbV5jpartSi88uUXzBVLBQkU

[chpio]

pinned files froze my browser (but that's another issue... again)

[dignifiedquire]

pinned files froze my browser (but that's another issue... again)

Fixing, that is a real issue

[chpio]

nah, it's because of the number of entries... pagination would maybe fix this

[dignifiedquire]

No more freezing QmU3o9bvfenhTKhxUakbYrLDnZU7HezAVxPM6Ehjw9Xjqy

[chpio]

lol :D nice fix

[nginnever]

Aside from Error: Unmapped range(…) and on load of connections page Error: Failed to lookup node(…) everything looks 👍

[whyrusleeping]

If everyone could test this webui version out asap that would be great.

Run your ipfs daemon with: ipfs daemon --unrestricted-api

and then access http://localhost:5001/ipfs/QmU3o9bvfenhTKhxUakbYrLDnZU7HezAVxPM6Ehjw9Xjqy
in your browser to try it out.

[noffle]

Lots of Failed to load resource: the server responded with a status of 403 (Forbidden). I'm running with --unrestricted-api on 0.4.0-dev. UI doesn't appear to be being populated with content.

[dignifiedquire]

@noffle does the regular webui work for you? sounds like CORS settings not being correct

[noffle]

@dignifiedquire It doesn't. My config:

  "API": {
    "HTTPHeaders": {
      "Access-Control-Allow-Credentials": [
        "true"
      ],
      "Access-Control-Allow-Methods": [
        "PUT",
        "GET",
        "POST"
      ],
      "Access-Control-Allow-Origin": [
        "http://localhost:3000"
      ]
    }
  },

[dignifiedquire]

@noffle add http://localhost:5001 to the allowed origins restart the daemon, and then navigate to http://localhost:5001/ipfs/QmU3o9bvfenhTKhxUakbYrLDnZU7HezAVxPM6Ehjw9Xjqy

[noffle]

@dignifiedquire: thanks, that did the trick.

It's working well for me. I played with all of the affordances and nothing is exploding (violently or otherwise).

[jbenet]

@dignifiedquire we should not have to add any CORS stuff to have the webui work by default. it should work out of the box for users. if it doesn't then it needs to be fixed.

[whyrusleeping]

@jbenet i think that @noffle had his config changed before testing the new webui leading to the CORS issues he had

[dignifiedquire]

@jbenet yes it works out of the box, but @noffle had a non default config, so it didn't work.

[jbenet]

@dignifiedquire ah ok makes sense. we should probably warn users that setting an origin like that will mess with the default expectations (or maybe we should just make the default config show the expectations)

[noffle]

@dignifiedquire Are you sure? I did a fresh ipfs init and see this "API" entry in the config:

  "API": {
    "HTTPHeaders": null
  },

[dignifiedquire]

@noffle works fine for me on master on a fresh init. Even though headers is empty, the default is set internally I think.