Hi Joachim,
Thanks for the compliment. Maintaining stability in a system as mature as VAST while still pushing it aggressively forward is an undervalued (or perhaps unvocal) art in the industry, so I'll pass on the compliments to the team.
Good...sounds like we are on the same page. I appreciate the thoughtful discussions you bring forth here. My only concern was that Instantiations silence might be interpreted strictly as "Instantiations doesn't care" either from you or anyone following along waiting for us to respond.
If we don't respond, it could be that we simply don't know and have nothing useful to add, or the Instantiations staff that would have an opinion simply are not here to voice it. Certainly never responding to anything would be kind of strange, but I think we respond to most topics, just not all of them.
Yes, I'm happy to put in the case for review.
I thought folks might appreciate some insight into the amount of energy that goes into evaluating even the most simple changes to the product and how seriously we take it. I used to be an application developer, and while backwards compat was a concern, it was nothing compared to platform development of a mature system with no end-of-life on any versions.
After so many incidents of being burned by the unforeseeable, my general approach has been refined to the following when looking at changes like these.
First, we classify the change. In this case, it's "base code". The most perilous area of all. When we see this internally at the company, our defensive mental shields raise to maximum:) . However, it's not quite "historical code", which is @1996 code. Thats the worst of all to deal with. This method was changed in recent times and I've tracked it back to Case 50663 which is based on your discussion with John to change Signal>>description (
https://groups.google.com/forum/#!topic/va-smalltalk/Fs6trFTfTs0). So here we are again:)
Next, we assume the change breaks something. Because this class of change usually does, if not now, then some years in the future as part of a customer migration from a team that no longer has the knowledge from the original team that built it a decade before and did something unforeseeable. The good news here is it was already changed once before in recent times and I don't recall huge fallout.
Then, we classify the breakage from the change. Since we assume it's going to break somebody, we need to understand both how the break occurs and how detectable that break will be (i.e. locality of the error to the change). In this case, we have a textual change, it's not localized to the method (i.e. that change is returned from the method and propagates elsewhere), and it's a public method.
Public methods mean automatic migration guide entries when changing args or return values. Naturally, we like to keep these to a minimum. But zero migration isn't realistic, so we obviously have to do it. But it adds more risk, even company perception risk because we have commitments for public methods and the more the contracts change to those, the less companies will be amenable to migrate. Likewise, its more expensive for us to support customers on older versions of the product. Private methods are for us, we will change them at will and with no notification...but that doesn't make it automatically safe.
A textual non-localized change means the probable breakage points are going to be with customer code that is parsing the result of Signal>>description to make a decision. The code may have a stream that indexes up to the ':' because they know whats next is mt, but now ':' won't be there with this change. The detectability of this change is not classifiable. It may be detected immediately or never. For example, if a logger is making a decision to log exceptions with certain descriptions and has the parsing logic I describe above, then nothing breaks...the logging statements will simply be absent. This may go unnoticed now, years, or never.
So finally, I take this pessimistic view of the world and roll it all up to help answer one simple question..."Is it worth it?"
Sometimes it is because not doing it would hold us back from moving the product forward.
Sometimes it is because the localization of the change is so high that it can't be conceived how it would break unless someone was doing really tricky code like looking into the compiled method or stack frame itself (yes...we have jaw-dropping examples of this from IBM base code).
Sometimes it is because the detectability is so high that we are willing to do a migration entry and know that even if folks didn't read the migration guide, they are going to have no other option but address this and see that it has changed. (obviously we assume the change itself was worth doing).
Sometimes it is because the code itself has a short history and is well understood by the current team enough to handle the change.
Sometimes it is because the area of change is in some obscure higher-layer corner of the codebase whose impact in any direction would likely be minimal.
All this to say, even small changes can require a lot of thought and time on our end.
Now scale this up to changes like "New UI Frameworks", "Unicode", "Virtual Machine", and you can start to see why these take years. And if it were any other way, we wouldn't have the product we have...we would have a product that breaks constantly or a product with a whole host of frameworks that we say we are unwilling to support any longer and rip them out of the product. There is one of those "Pick 2" Triangle diagrams with the labels Fast Delivery, Cheap and Stable somewhere in here:)
My statements may indicate that we won't do this. But, that hasn't been decided since we have not performed the mental exercise yet. The strongest point in favor is that it has changed in recent times. The points I don't like is that it's in base code, public and textual change that is not localized to the method.
But, it will be considered for sure.
- Seth