Currently there is no way to know what has changed other than the sporadic announcements. Even if it is something as generic as “Bugs fixed” would be helpful, at least that lets us know there was no new functionality.
As it is, I’ve had several updates and have absolutely no idea what has changed between them.
Consider adding screenshots and as many details as possible, to help the Shapr3D team and the community understand why you need this feature. Describing your workflow helps us building the right feature.
Knowing that there are new features or even ones that have changed is helpful. Knowing that bug fixes occurred is helpful. We appreciate the frequent updates, but knowing what was changed helps US in knowing what to expect.
Brief description of the outcomes that you expect from this feature:
Some transparency on what changed so there are no undue surprises.
Eg. “this feature should allow me to edit and create constrained assemblies with 100 000+ parts” or “using this feature I should be able to create G2 continuous lofts and manipulate the shape real time” or “with this feature I want to be able to quickly find a part in my designs by searching for its name”.
Understanding the outcomes that you expect from this feature helps us more than describing an actual implementation of the feature that you’d expect.
What can’t you achieve without this feature?
It is more of a courtesy to your paying customers that you are being forthcoming about the changes that occurred.
Is this a workflow blocker for you? Is this why you can’t use Shapr3D for work? Is this slowing you down?
It keeps your customers in the loop. The last announcement was for 5.320. We are at 5.332. What changed? I’ve no idea.
There are announcements for every release. Whenever a major new function is out, it also gets it’s card in the app’s “What’s new” section on the Discover page.
Unless I misunderstand what you mean by release, release 5.330 is not the same as release 5.332. Some companies are very cognizant of customers need to know what changed (because it can affect our workflow — sometimes dramatically). Again, this is purely for transparency as it does help us.
By assuring there is a text document with the DMG file (we use MacOS). This is especially handy for those who keep multiple copies of the app in case new versions disrupt their previously established workflow.
The reason minor versions don’t get release notes, is that we don’t release features with them, and bugfixes are only mentioned even in the major release when they have a significant impact on user flows (which they relatively rarely have).
To put it simply:
The releases we release every 2 weeks get release notes / forum announcements, and what’s new cards when a feature gets released (they are ending with 0 in the version number), minor versions (ending with numbers other than 0) don’t.
We are a games development house and in Unreal, there was a bug that caused the system to crash. So for months we avoided using that (even though it created some issues). When it was fixed, we were able to use it again and make changes sans crash.
As much as we would like to believe our code is bug free, the harsh reality is that problems do surface and users have to change their workflow (an example would be exporting OBJ files: we CONSTANTLY have to turn off vertex colors because S3D does not save the settings — which I documented here).
As harsh as it may sound (trust me, I’ve been on the dev side for over 40 years), users do not and can not keep up with each company’s rules for releases. Your code is only one of many we use for development (and this doesn’t count our own).
Knowing what areas have changed can have positive, or negative, impacts on workflow. Knowing in advance is helpful, provides a modicum of transparency and is useful to end users. A good example is GitKraken which shows a tab of changes in their software.