Also, while experimental, I am really looking forward to SVN finally having some sort of stash mechanic via shelving.
Thanks for the quick response.
I'm not worried about SmartSVN naming but am concerned that the program might be incompatible with svn 1.10. I don't need the experimental features: it would not be a deal-breaker even if they were supported by the binding you use. At the moment we would like to use the command-line conflict resolver but are unable to upgrade to svn 1.10 because Eclipse (which we use as a graphical client for repo browsing and most commits) won't run with it due to the "wrong JavaHL version".
Can you confirm that SmartSVN 9.3.1 will run with a Linux system that only has svn 1.10 installed (or svn 1.11 when it is released)? If so, the infrequent releases of SmartSVN will not be a huge issue.
I agree that companies don't like weekly or monthly releases of products but there has only been one major release and one point release of SmartSVN this year: there is some frequency in the middle. Aligning with the major Subversion releases, even if it just ensuring you can work with them, seems reasonable. Subversion 1.10 has been out for nearly six months and some notice of compatibility is essential. An indication of the plan for supporting new features would be helpful too: I realise you are limited by the API but will the conflict resolver be implemented (and experimental features?) when svn 1.11 improves the api?
I'm a bit late to the conversation, but want to add that I'm planning to stay with the 2-year LTS cycle. I think that should be acceptable to majority of your customers.