The core and driving reason we do not patch older versions after their end of life is due directly to the way we build the software itself. When we maintain a "build", even though it might LOOK very similar from one version to another, it is a separate line of development and takes. Vectorworks 2018 and 2019 may look very similar certainly from the UI side, but they have many very different and incompatible components. This means a number of things that influence what we can and can't do:
1) When we fix a bug in a newer version of Vectorworks, that fix doesn't always work/apply to a prior version. That was the case with the section line appearance bug and quite a few others visual issues in SP2 for 2019, the fix was a change to the VGM that without significant modification, the previous versions could not accept. Effectively, we would have had to put forth the same effort to fix 2018 separately from the effort to fix 2019. This is why the issue did not receive a patch.
2) Once we release a version of Vectorworks, within days, we start work on a newer one. However, it can be a bit obscured to users how many versions of Vectorworks we have up in the air at any one time. For example now that 2018 has been sunset/reached end-of-life, we are maintaining Vectorworks 2019 publicly and Vectorworks 2020 internally. In addition to that, we often have engineers working on what will be Vectorworks 2021, or at the very least on features that depend on features that won't exist until 2020. This means that we already, at minimum, have to maintain 3 separate development environments/developer environment versions just to maintain regular operations as we do today.
3) We do indeed have to make a call on things like "How much are we willing to slow or cancel current support and future development to maintain older versions?" and the answer has been since I worked here "For one year after release."
The way that many companies have chosen to address this, is to either go completely versionless or web-based, where you always log in to the latest version of the product and you have no control over the versioning, or they offer some sort of maintenance plan like we do with Service Select. However, since in this industry we are one of the (not few but certainly smaller than the big guys) holdouts that are not forcing subscription programs on users we are definitely going to have a higher percentage users who are used to the older purchase models like we had pre-12.5, where you bought a version and used it for a number of years before switching. This is of course a personal preference kind of thing, but I'm personally in the camp of wanting to own what I paid for after a handshake. I do not think we will be changing this any time soon. We may offer monthly or yearly subscriptions as an option for students and companies who ramp up and down their staff frequently, but I do not see us forcing this on the entire user base.
Now, this is all aside to the OTHER core issue here, which from the users point of view is (please forgive my dramatic oversimplification): "I bought a Thing2. That Thing2 doesnt do what I need it to do, which is one of the things it is supposed to do when working normally. Thing1 I owned last year did it and still does. Thing3 does it too, but I already own Thing2 so why should I have to now buy Thing3?"
That's the harder part for me at least. But looking across the vast sea of software packages, that's the norm. This has always bothered me. We can go with the car analogy as well, if I bought a car from Honda and the one they sold me just doesn't stop when I hit the breaks, it wouldn't matter if OTHER people weren't experiencing this problem, I'd be able to get a replacement car from Honda right away. This reality just isn't so in the software industry. I have no answer for that, it's bigger than I will ever be. I never like the "That's above my pay grade" moments but this is a big one.
I would suggest that the reason the industries differ so dramatically is because 1) software generally can't cause a deadly accident. 2) software updates come, by design AND by demand, much faster than the development of things like microwaves or cars or skyscrapers. Speed is often favored over attention to detail. Quantity over Quality. That's very much the direction we started to head awhile ago (2009ish) and was exactly why we have the quality issues we have today.
That kind of leads us here: It is absolutely and completely up to YOU to decide whether we merit your money, which you of course know. But if you believe that we are attempting to wring money from users unfairly or that we intentionally refrain from patching old versions, then I would absolutely understand if you no longer wanted to do business with us. People don't come to this forum for no reason, they don't post things expecting me to throw them candy, they post because they either want to gain knowledge, or they want the product to be BETTER. If they wanted another tool that was already available, they wouldn't be posting here, theyd've already moved on.
The positive change I've wanted to see in this company happens with increasing frequency, but quality is not simply a switch we can flick and leave in place. It was a change to how we reviewed tasks, chose features and drove development. I have now watched engineering managers rank up to directors and vice presidents in this company. They know their stuff, they know what's possible and what's not, and they know the product more intimately than I or many users here probably can. The right people are in the right places, heck our CEO started out as one of our first engineers. We don't just pluck staff from the job market bucket, their (and my!) lives are deeply interconnected with this company and Vectorworks itself. We don't make decisions with the intentions of stiffing anyone, there's no Scrooge McDuck-ian vault of gold coins that the VPs swim in or I would absolutely post pictures.
I am more than willing to discuss this or answer any questions I can.