Backward Compatibility Limits

[Hexspa]

Hi. I'm arguing that backward compatibility should only be valid for one major release version. So, for all of version 14, backward compatibility can be a valid reason to keep existing issues. Any technical flaw or severe usability issue should be corrected by or during the next major release.

Backward compatibility is a noble cause but it should not stand in the way of present and future improvement. In any case, its implementation has not been consistent. Besides, any time I've seen BC broken in the past year, very few users here have complained.

VST plugins are not operating systems. Nothing is built on top of them but merely with them. They are not the foundation of the structure but the tools of construction. If a user has a project from a year or more ago they need to open, it's more trivial to freeze or bounce a few tracks - or simply not update - than it is to work around several illogical design flaws.

That is my argument. I'm interested in hearing what the other community members have to say.

Thanks.

[mibby]

I'm arguing that backward compatibility should only be valid for one major release version. ...
Backward compatibility is a noble cause but it should not stand in the way of present and future improvement.

I agree. If it's an "active" project, the plugins should be kept up to date in the project anyways. If it's an old project, the previous plugin versions are readily available to download. I'll add that Vojtech's release notes are second to none in the world of plugin devs so you can always see what has been done.

However, something that would be SUPER helpful, is simply a "release date" along with each of the versions...

[mibby]

Maybe the date stamp could be rolled into the version number as a sufix? (i.e. Release 15.00k.20210517 or 15.00.20210601 for a live release date of June 01, 2021)

[Kumal]

I think it's not as easy as you might think. Certain projects need to be worked on for months or years and compatibility is a thing. And when projects start overlapping in time you'd effectively could never update the plugins.

The issue is rather the plugin kernel concept of which can exist 1 only on your system. Else you could easily keep old versions of individual plugins installed. Another idea would be to make some major version and actual new version with a new ID and such.

[Hexspa]

Good discussion. Thanks for joining.

I'm definitely in favor of the YYYYMMDD_24HR time format. It's the best one for sorting by name in file lists. Dating releases can't hurt.

Kumal, you make a good point about some projects taking years. The other point about the kernel is one I hadn't considered.

The thing is, I'm not specifically referring to project-destroying changes. Hopefully there aren't too many of those lying around anyway. A specific feature I'm talking about is the dotted delay mislabeling in DelayMB. Of course, I'm no developer, but that seems like an easy enough update that shouldn't destroy a long-term project.

Thank you, everyone.

[Held]

On the one hand, I like being able to update plugins whenever I want and be confident that nothing is going to break, on the other hand, there are some things that could use an overhaul.

I guess adding the version number to the plugin name and only have breaking changes for major releases could be an option. So you can have MDelayMB14 and MDelayMB15 installed at the same time. But then you have the question about sharing presets, wave tables, etc. between versions, so it's probably a bit more complicated than it seems.

But when you consider that V12 made people remap their MDrummer automation because the parameters were restructured, making people update their delay times because MDelayMB changed the dotted delay labels seems to be in the realm of accepted changes.

And since there aren't that many complaints about the dotted notes, not many people seem to use that option anyway (myself included so far).

[Hexspa]

It's true that some renovations require more heavy lifting. By no means do I want do destroy anyone's workflow. It's just sometimes I see things that I think would make more sense a different way.

Usually I propose such a way, along with my version of a rational explanation. A few things can happen: Vojtech agrees and implements, Vojtech vetoes without recourse, or we can discuss Ay and Nay.

At the end of the day, I feel like more suggestions are better than fewer.

Cheers.

[MeldaProduction]

Nope, sorry, I want to keep as strict backwards compatibility as possible. It's like superdifficult with the hiddeously huge feature set, but without it many people would be doomed...