The JADE 2022 release meets tomorrow’s business demands.
Currently, the IDE can only be updated by upgrading the whole JADE environment.
As much as developers would love to upgrade as soon as we can to benefit from IDE improvements, the decision to upgrade is generally out of our hands as it is driven by business needs. For an organisation with a large system developed in-house there can be a lot of effort involved in testing an upgrade to ensure it'll have no adverse impacts on production systems, the cost of which needs to be weighed against other business priorities. For software houses, whether or not they upgrade may be dictated by their client needs, who may not see the benefit in upgrading arbitrarily without any discernible system improvements.
What I'm calling the JADE Runtime includes the RootSchema, language, compiler and any other functionality which if changed would affect our production systems. Changes to these components should be released infrequently (as is the current cycle).
Whereas we need IDE changes to be released more frequently if we're to gain any immediate benefit and be able to provide meaningful feedback soon after they're implemented.
Understandably, upgrading the runtime would depend on upgrading the IDE to the next major version, nor would we be able to jump to the next major version of the IDE without upgrading the runtime (because the IDE depends on the latest runtime to support/use new language features), but most IDE changes we talk about don't necessarily depend on changes being made to RootSchema or the language so it should be feasible to implement IDE improvements without changing the runtime our systems depend on.
Kevin Saul
It might generally be beneficial to decouple development and runtime. It would be great if developers were able to select, instantiate, and deploy to a runtime instance for debugging and testing.
@BeeJay - Some of us will code & test in environments with data in them, where we wouldn't want the runtime to be upgraded beyond the current version used in our production systems. Hence, the primary objective of this idea is to remove the tight coupling and get us into a position where we can just upgrade the IDE, without needing to touch any of the runtime components that our systems depend on, whether that be in production or test. Beyond that, I do like the idea of having other options that'd support targeting previous runtime versions, in addition to what you've suggested it would also be good to have some kind of preprocessor flag (a variation on executeWhen perhaps?), which checked the current runtime version. This'd allow us to maintain/compile old & new versions of the code, where the old versions would be kept for backwards compatibility to workaround old/known runtime issues.
For the current release cycle, I certainly miss it significantly when I’m having to do a HotFix on a release of our product that is on a Jade version which is too old to have the Ctrl+6/7 support as that has now become second nature in my standard daily workflow. To be able to get these sort of IDE improvements, but still being able to guarantee you don’t use features which aren’t supported in your deployed systems Jade level, and guarantee that your schema extracts are compatible with the deployed systems Jade level, would be an absolute boon to developers using Jade to write their applications. In other words, while the Jade IDE is very tightly coupled to the underlying Jade version, if there was somewhere within the development environment you could set your target deployment Jade level, then have the IDE & compiler block you from using features and constructs which aren't supported in that version of Jade and ensure that the schema extracts are 100% compatible with that target version of Jade, then that could allow the development environments to be upgraded to a later Jade release, allow developers to benefit from these IDE improvements, whilst still ensuring you can ship releases to Production/UAT/Training etc environments which are still running on older releases of Jade.