As the main developer of the Syncthing for macOS wrapper I would like to know if we could push the v2 as main version and abandon the v1 for auto-updates. I think only bugfixes will be ported between version unrelated major index db change. Let me know what the roadmap is, or if there is a roadmap written down somewhere. When agreed I know if I can push a override from v1 to v2 for mac users automagically (via Sparkle updater framework). People are unable to downgrade (by design). Also if there are some extra changes in the pipeline for v2.1.x then i’m not hurrying to push out this major version upgrade (just yet).
Thanks all for the hard work and making this possible.
I don’t know precisely what you mean by this, but I think this is what we’ve done, more or less.
Further v1 releases will be in case a significant problem (probably security) is discovered and we need to roll out an update. v2 is definitely the “main” version.
I have reflected almost same branch naming in the syncthing-macos sub-project but make use of develop/release branch naming. v1 “release train” is now currently on develop/release and v2 is now just in “pre-release” mode. I still want to make sure its “a little more mature”, waiting until v2.1.x is out and then abandon v1 and swap out release branch for v1 and v2 branch for develop/release. Hope this clears things up.
Frankly, not entirely. Your branching is your branching, I think what matters more is what is provided to users in terms of downloads and upgrades. Syncthing v2 is the thing we link to on the download page and what I think every new install should be. Upgrades are still not automatic for a couple of reasons, mostly that there are some behavior changes and it can take a while, so springing it as a surprise on people will probably not be widely appreciated.
I do think it’s important that there is a way for people who run syncthing-macos to get on 2.0 as we’ve been providing that upgrade path everywhere else for a couple of weeks. Waiting for 2.1, whenever that may be (really a factor of when a new feature triggers the versioning bump), doesn’t necessarily seem like a good criteria to me.
At the same time, I do not think you should auto upgrade v1 users to v2 at this time. Probably still not when release a 2.1. Maybe this is not possible to reconcile with the point above in your upgrade framework? It also wasn’t in for example the Debian/API packages, so we publish v2 there as a separate component which can be intentionally upgraded to, but is not an automatic upgrade.
This answers my question, but in a better way then expected. I will maintain for now two versions then. Need to figure out how I can mark things pre-release in the Sparkle update framework. I know it is possible. As indeed v1 is proven technology, still we need to iron out v2 and get more runtime hours and adoption. Thanks for the response.
Your branching is your branching, I think what matters more is what is provided to users in terms of downloads and upgrades. Syncthing v2 is the thing we link to on the download page and what I think every new install should be. Upgrades are still not automatic for a couple of reasons, mostly that there are some behavior changes and it can take a while, so springing it as a surprise on people will probably not be widely appreciated.