I’d really love it if there were some sort of long-term support edition of dagster. My team can’t keep up with the release cadence of Dagster currently. New features are added, which is good, but also experimental APIs are frequently changed. This is reasonable - they are experimental, after all - but it makes our upgrades relatively rare. We use those experimental APIs because they’re often the only option available. So we can’t realistically upgrade without losing a day or two to working out changes to experimental APIs, which often aren’t detectable until a few days pass and jobs actually execute in production on our real executors. Rare upgrades are problematic because we don’t get bugfixes. This has actually led us to stop reporting bugs, because what’s the point - we’re not going to be able to incorporate the fixes anyway! It would be so nice if there were a release that freezes the API to a stable subset, but gets backported bugfixes. For example, a

1.2

LTS edition which gets fixes for severe bugs, but no API changes or new features. Then, my team could just update often for the bugfixes, and then when new LTS editions come out, we can dedicate time to upgrading to get new features if we like.

Hi Spencer - curious, what experimental features are you depending on?

Let me see if I can list them, I think it’s lots, but asset’s

code_version

and sensor’s

asset_selection

come to mind. I seem to remember some part of PartitionMappings being experimental but I’m having trouble tracking that down

Got it. Also, I hear you on the larger issue. I think it's very very unlikely that either

code_version

on assets or

asset_selection

on sensors will change or go away. If the auto-materialize APIs change, it will be to give them new names that make them feel less isolated from our imperative scheduling APIs.