For my app, I have hundreds of feature requests, and for 95% of them all I can say is, that's a nice idea, but I don't have time to do it.
For the remaining 5% it'll take me a year or longer to implement them.
For customers this looks like I'm unresponsive.
When I started out, I often added features in a few days, and customers were thrilled, but that low-hanging fruit is mostly gone now.
I do, however, think you need to balance big featured with quick wins that make a subset of your clients significantly more happy.
If I share a public roadmap, and then I don't deliver, people will be disappointed.
So I've started to only tell people about new features once they are stable enough for testing.
I don't want to build up expectations when I'm not sure when/if I can deliver.
I agree. Your public roadmap should be conservative, or more oriented towards the type of impact you will be making. The intent of a roadmap is to communicate your focus so that folks outside know the general theme. You then have something to reference in conversations later when someone asks for something that doesn't fit with the theme.
Personally I have found any type of feature and expectation discussion easier in person or on a call. I expect feedback over the internet to be poorly phrased or hostile. Expectations break down if you have any type of sales team who are prepared to offer features to close deals.
It looks like you make a database management app for the Mac. If I was creating a theme-based roadmap I might choose a theme like "SQL Console Improvements". You can explain that your focus is on that area of the product, but that your focus may change in the future. When you get close to being certain a feature within the theme will be developed then publish that information. You can operate multiple themes depending on resources.
This approach can also work for feedback. You can let users know that the next theme on deck is "Optimization Tools" ask for feedback on how users want to improve their SQL queries. Then when you start executing on the theme you have collected feedback that can be incorporated. The flow makes users feel involved in the process. Actually summarizing the feedback in public can be a useful community exercise for expectation setting when everyone thinks they have the most important idea.