Release 2.0.3.1 (experimental) 2018-03-16


#1

2.0.3.1-2.0.3.1_experimental_2018-03-16

This experimental release is mostly the same as the canary build v2.0.2.20.
Some of the major changes from the experimental build 2.0.2.15 are:

  • A new UI for setting the retention policy
  • Added an rclone backend
  • External links in the UI are now marked
  • Fixed a number of browser cache issues, which should fix the XSRF errors
  • Optional warnings when reaching the quota limit
  • Fixed not attempting to read non-symlink reparse points on Windows
  • Fixed a problem with the box.com backend
  • Fixed some crashes that were caused by the usage reporter filling up reports
  • Option to disable the file-size read-ahead scanner

#2

Would this be considered a “downgrade” if I have the latest canary (2.0.2.21) already?
Edit: I see there’s also a canary build today - I assume that would be the one I want if I have been using canary versions, correct?


#3

Nope. The Experimental release starts the 3.0.3.x versions so it should be an upgrade from anything in the 2.0.2.x line.

If you want something with fewer updates and more stability, stick with the Experimental release.

But if you like the frequent feature updates and bug fixes of canary, then going with the Release: 2.0.3.2 (canary) 2018-03-16 release is a good idea. (Note that 2.0.3.2 Canary already has 4 new features not included in the 2.0.3.1 Experimental release.) :slight_smile:


#4

I would have figured that, except for the following detail:

(Seeing as how I was already on 2.0.2.21, which had certain additions over 2.0.2.20).

yup, that’s me, lol. tips fellow developer hat


#5

Ah, right - I missed that 2.0.2.20 vs. 2.0.2.21 difference, sorry. I expect that was a typo but we’ll have to wait for @kenkendk to confirm.


#6

It’s no typo. It is based on 2.0.2.20 but with most of 2.0.2.21 features added. There were just a couple of things in 2.0.2.21 that wasn’t ready to be promoted :slight_smile:


#7

Yes. Usually the experimental is based directly on a canary build, but in this case there were some features we had tested in the 2.0.2.21 build, but also some non-essential fixes that we decided could use more testing.

The solution was to go one version back, and then just merge in the fixes we wanted.