I just saw you released 3.7.1. It seems that the download link only lets you download 3.7.1.
Where can I access the download for 3.7.0?
Thanks
Yan
Old SDKs are not available for download.
We recommand to always use the last one.
In github you could access the history (versioning) of vstinterface and helper classes
This is the only project I know that does this… Do you realize that people cannot switch like this overnight especially when they are in the middle of a project? This is so developer unfriendly!
You switch without any warning, while making backward incompatible changes (like changing cmake function names and variables), and you don’t offer any access to previous version.
I am not sure how you would react if CMake, for example, that you currently use (and you use version 3.4.3) would tell you: no way, you must use the latest version 3.18 and we don’t offer any download of past versions…
Yan
like i said you have VST cmake, VST Interface and helper classes in github… up to version 3.6.7
you can use the tags:
A text file which describes the necessary changes to port a project created with the previous SDK would be really helpful
1 Like
It’s generally a best practice to put your dependencies into the same source control as your “actual” project.
And by “best practice” I mean “something everyone learns after they get burned once,” kind-of like “making backups” or, indeed, “using source control.”
Not trying to be that guy who brings up what can be a heated topic but I have to agree with the others and I believe some improvements can be made to the process.
Just to illustrate the problem:
Fact of the matter is that even when minor versions are released, there are breaking changes either in API or in build configurations, which require an update to projects before they can work with the new SDK. This is fine as that is the way of software development and I find these changes and their migration strategy well documented in your changelog, so no complaints there.
However in the situation where there are multiple VST projects that are developed and deployed individually, it becomes a hassle to update all project code in one go in order to be able to switch to the latest SDK. As such, myself and most people in this thread prefer to have access to older SDK’s while they migrate their legacy projects in their own time, one by one.
I don’t find it a problem to maintain multiple SDK versions within my build pipeline, but these projects won’t scale outside of my pipeline if others can’t easily access the original SDK’s. I have seen open source VST projects that keep clones of older Steinberg SDK archives within their repositories just for this purpose (!).
I think the way your releases are tagged in the Git repository are very helpful, but truth of the matter is that the contents in these tags are not equal to a full SDK release and need to be hand assembled with dependent source code that we need to pull from the latest SDK release. I get how you separated the concerns of the code logically, but from the perspective of having a ready to use API package for third party developers, the code is incomplete.
I have seen this topic come up over the years and the replies usually to be “paste tagged Git code over the last SDK” without further information. While I don’t want to make this about “tone of voice”, I do want to highlight that we have a gaping hole in developer experience here. As developers keep bringing this up over the years it means either their expectancy on code distribution differs from yours or that there is missing documentation on how to do this or even what the rationale is for simply not storing the previous archives indefinitely on the Steinberg site. We’re not doubting the rationale of the Steinberg development team, we just’d like to know what it is.
I think the release of 3.7.2, which is a broken release (see vst2 wrapper assert failure and json parsing issue on win10), simply demonstrates another side of this problem. Because the only full sdk available is the “latest” one, anybody downloading the latest one gets a broken one, with no way of downloading a non broken one. As you stated, github is not the full sdk. At this moment, there is just not a non broken sdk available.
Here is a very simple way to fix this issue: since the source code is already on github, why not use the release feature on gihub to simply attach the full sdk as one of the binary of the release? It wouldn’t be on the Steinberg website, but at least it would be attached to a github release tag and available to anybody who needs it for any kind of reason. The website could simply point to it for “old” sdks… This is actually how I distribute my own vsts (see example) so there is a history of all the releases and they are properly attached to a github tag…