v0.9 development

Development
1

I’m soon going to commit some backward incompatible changes, so the master branch is going to become v0.9, with a new branch v0.8 for bugfixes etc until v0.9 is released. I expect there to be at least one more v0.8 patch release before v0.9, but I’m going to try to avoid merging any new features to it.

I did ask what the focus for v0.9 should be, and I did hear and consider the responses. However, v0.8 has lived longer than I anticipated and as things turned out I think v0.9 needs a different focus - scalability and reliability. Specifically I want to address memory usage for large installations, connection setup efficiency (index exhanges etc) and squash the remaining sync bugs. This will require some fairly large changes to how information is kept (i.e. on disk database) and some protocol changes, hence the new minor version.

As a side note, v0.9 will require Go 1.3 to build. The currently available 1.3rc2 release candidate works fine.

2 Likes
2

Does that mean some kind of fast-resume when nodes reconnect, either by exchanging diffs of index files or just skipping index file exchange when the repositories haven’t changed (exchanging multiples or tens of MBs of indexes every time nodes connect is not ideal).

3

I’m thinking keep the other nodes’ indexes persistently, announce the maximum known version number on connect. The other node then only needs to send an index update for entries with higher version numbers. Basically what happens now after the initial index exchange, just with the index exchange being implicit instead.