Afaik from SWE the 3 digit versions and increments of them have the following semantics…
- Major Version: Complete Overhaul - Patches not compatible at all
- Minor Version: Change in Features. Mostly adding things which mostly should keep compatibility. (Deleting funtionality would break compatibility).
- Patch Version: Compatible change, mostly cosmetics or fixed bugs. Should not add new features or create any incompatibilities.
(My List is here for intuition, not for doing a exact, scientifically correct definition)
That means that I could load a patch created in Version 1.0.x in any Vital Version 1.0.z regardless of z bigger or smaller than x.
That would even support what you (@Tytel) have said on KVR about notifications about new versions: “I’m only going to put out notifications for some builds because I’m doing some quick releases in the next month (1.0.5 is coming soon) and I don’t want to ping everyone for each one.”
Why I say this? Vital refuses to load a 1.0.4 patch in 1.0.3. I would figure that the difference in Vitals Code is only fixed bugs, no new features that would render 1.0.4 patches unusable in 1.0.3. And I did not upgrade because I haven’t had any issues with the 1.0.3 but read some headlines saying “GUI glitches” with the new Version.
@Tytel: What do you think.
It’s not uncommon for patches created on a new version of a plugin not to load in older versions regardless of changes made.
For the record I have had no issues with 1.0.4 and it does address some issues like patch names not being recalled in projects.
In my opinion there is no reason to stay with 1.0.3
It’s also not uncommon for support for older versions to end when a new version is released.
Yeah I’ve already switched to this setup in 1.0.4
So if you’re on 1.0.4 you’ll be able to load 1.0.5 presets.
What would be the point of using 1.0.4 if you’ve released a 1.0.5 ? I imagine you’ve got enough on your plate having to support Win, Mac, and Linux versions without having to support legacy versions of Vital as well.
Bug regressions normally - it happens
Indeed. There is a regression that breaks Linux Vital 1.0.4 on machines running an NVIDIA card.
Ah - is that what causes it to crash when loading the interface - weirdly only as a plugin - seems to work standalone!
For me the crash was in the stand-alone. With the LV2 version both from jalv and qtractor, it would hang. I have another Linux box which is basically the same as far as processor type (3rd gen core-i) and OS (Slackware 14.2), but it differs in that it has only the on-chip GPU, and Vital 1.0.4 comes up on that box just fine.
If you’re not using the latest version then you’re not helping the development of Vital. Sticking with an older version doesn’t help.
If you’re having bugs in 1.0.4 then report them and help the developer find out what’s wrong so he can fix them.
For the record 1.0.4 works fine on my nVidia card.
Are you using it under Linux on bare metal rather than through a VM? Again, I can’t run 1.0.4 because there is an immediate crash with the stand-alone and a hang with the lv2 plug-in. I run Vital as a musician rather than a developer. Crashing and hanging don’t help me play my music.
And how would the developer fix those crashes if people don’t help him ? Report it, give as much information as you can and help test any future versions.
No crashes here on Windows 10 with an nVidia card because although I do use Linux I don’t use it for music. Too wonky.
Is this really going to be one of the longest threads now?
- Matt already wrote that he will support preset loading as I have suggested with Veriosn 1.0.5
- Whenever I have upgraded but figure I have a problem I can still report that problem AND…
- … switch back to the previous version and finish my work BUT …
- … I can still use Presets created for the current version
And if I’m content with the current state of afairs and don’t need to immediately switch (because I want to finish some piece of music … want to or “have to” … I mean there are people with time lines here) I can keep the version and still use the newest patch level presets…
And it as well fits with the plans Matt has for announcing Vital software patches.
I see only advantages … I would like to understand what the disadvantages are and what we really need to discuss?
We really need to discuss the logic in using an older version. Unless you don’t trust Matt to make newer versions even better…I do.
Unless you think even minor point versions shouldn’t add new features that could expand the range of sounds Vital can make or improve existing sound design features. Or you think 1.0.5 should only include bug fixes which for whatever reason you don’t want to take advantage of. That’s certainly not logical.
Or you think that other people should use 1.0.5 to make new patches for you while you stay on 1.0.4 which seems rather selfish to me. I guess they don’t have “time lines”. You’re saying “hey everyone test 1.0.5 for me while I stay on 1.0.4”.
Sorry I’m just thinking about what’s best for Vital not what’s best for me. I guess I should really stop doing that.
I’m sorry teksonic, you’re on the wrong track. Semantic Versioning in Software Development is exactly as I said. I work in IT for a little moren than 20 years as a SWE and all OpenSource stuff on my radar - mostly - adheres to this Versioning scheme. https://www.geeksforgeeks.org/introduction-semantic-versioning/
If I’m not affected by a bug, for instance something in linux, I don’t want to bothered by an update especially not through the backdoor,
I’m sorry but you’re way off in the land of practicality. I’ve been on a lot of private beta test teams for plugins you probably have in your folder and while the “Semantic Versioning” you’re complaining about may be technically correct it has no real practical advantage. You’re just being pedantic.
Once a new version is released even a minor point version the developer should no longer have to worry about supporting that older version. He shouldn’t have to worry about backwards compatibility. Patches made in 1.0.3 should work in 1.0.4 but there should be no concern that patches made in 1.0.5 work in older versions.
Let me ask you why are you on version 1.0.4 ? Why didn’t you stay on 1.0.3 or 1.0.2 ? Perhaps because newer version bring improvements ?
You’re saying that Matt has the skill and talent to create an awesome instrument that you love enough to include in critical projects but doesn’t have the skill and talent to make improvements in new versions. Does that make sense to you ?
Of course having worked on many beta teams I know that no matter how large a team there is and how diligent they are in testing that bugs and issues can slip through. That’s when the general user base can help by finding those obscure bugs and help the developer fix them.
What you’re saying is that you shouldn’t be part of that process and everyone else should do the testing and you should just reap the benefits. Again that’s incredibly selfish.
But you don’t want to be “bothered”. I guess the rest of us will have to be “bothered” by testing new versions for you.
Nope. My 1.0.3 was perfectly okay. I did 2 complete tracks with it. I only updated because I was forced to. Because all guys jumped on the 1.0.4 which fixed some linux bugs which I didn’t care about … even the windos guys jumped on it because bleeding edge is always better, isn’t it.
And yes I’m pedeandic if being pedantic means using engineering pracice and sound reasoning. You should work on your assumptions - might hold for you personaly and your personal expectations, your personal way of dealing with Vital but might not for others. I’m not in here for beta testing. And I bet paying customers aren’t either. There’s people who want to make music and don’t care about a 1.0.4 that fix some linux bugs.
The way it will be implemented by 1.0.5 and onwards is the best compromise. Read my summary.
Over and out.
I think we’ve said everything we need to say. closing the thread