Increase the version of upcoming branch

[glassez]

Otherwise it is hard (or even impossible) to maintain compatibility of applications with release branches and master branch simultaneously.

[arvidn]

there's a script called set_version.py which updates the version in a few other places also.

I'm interested in keeping master as API compatible as possible with 2.0.x, so please let me know if you come across some incompatibility you think should be fixed. (accepting session flags in the constructor to be able to start in paused mode is on my list already)

[glassez]

I'm interested in keeping master as API compatible as possible with 2.0.x

Do you talk about full compatibility, i.e. with deprecated-functions=OFF?

In any case, as long as master has differences from other branches, it should have a different version (or some other convenient way to distinguish it).

[glassez]

please let me know if you come across some incompatibility you think should be fixed. (accepting session flags in the constructor to be able to start in paused mode is on my list already)

Other than session flags in the session constructor (and new disk I/O type, of course) it is currently only the following:

libtorrent/include/libtorrent/torrent_info.hpp

Lines 60 to 65 in 283cea5

	#if TORRENT_ABI_VERSION < 4
	// http seeds are different from url seeds in the
	// protocol they use. http seeds follows the original
	// http seed spec. by John Hoffman
	enum TORRENT_DEPRECATED type_t { url_seed, http_seed };
	#endif

I'm interested in keeping master as API compatible as possible with 2.0.x

I doubt this is really a good idea. We don't have the ability to make changes affecting the API/ABI inside the branch, and now we won't even be able to do it with larger updates?

[arvidn]

Do you talk about full compatibility, i.e. with deprecated-functions=OFF?

Not necessarily. But things that are not deprecated in RC_2_0 should at least still be available in master, albeit possibly deprecated.

In any case, as long as master has differences from other branches, it should have a different version (or some other convenient way to distinguish it).

Definitely. master is still a bit of a moving target though, until it's released.

I doubt this is really a good idea. We don't have the ability to make changes affecting the API/ABI inside the branch, and now we won't even be able to do it with larger updates?

I don't know what you mean.

[arvidn]

There's one place in docs/hunspell/libtorrent.dic where the version number is mentioned, and it's not updated automatically by the script. That's why the spell check is failing right now.

[glassez]

I doubt this is really a good idea. We don't have the ability to make changes affecting the API/ABI inside the branch, and now we won't even be able to do it with larger updates?

I don't know what you mean.

From time to time, there are some improvements/fixes are offered (and maybe you yourself have some ideas) that could change the API or ABI. You can't accept them into the current release branches (RC_1_2 and RC_2_0), so we're either left with nothing or forced to use some kind of workarounds on the application side. But we still hope that these improvements/fixes will be accepted into the master branch, so that they will get into the next minor/major update.

[glassez]

@arvidn
How about type of web_seed_entry? Is it even useful in current API?