ICC 2025 covered versioning changes that are coming where there will be long term stable builds that are considered safe and good for use in change regulated industries like Pharma (IQ/OQ/PQ). The slide showed that happening at 8.3.8.
Was that an actual target of when you expect to start rolling out the long term stable builds or was it just an example to illustrate the idea?
Do we have a relative ETA of when this is expected to go live?
Take this with a grain of salt because I don't actually know what slide or information you're referring to, but my understanding of the versioning strategy going forward is:
2027.2.0. This will receive regular updates over the course of the year.I suspect you might be thinking of this new definition of LTS...
I am. Thank you for the clarification.
See this blog post:
The detail you cite is in the animated release train graphic.
Thanks Phil
Does this mean that the module major versions in 2028-LTS.0 will be the ones from 2027.2.0? And therefore different from 2028.2.0?
Or will 2028-LTS.0 and 2028.2.0 use the same major versions? Or something else?
I'm preparing to write up a new purchasing and support policy that I'd like to sync up to the LTS major module versions.
First thing: nothing's going to be published at the coordinates YYYY-LTS.0. That crashes and burns any tooling that follows Semantic Versioning.
Module versions still look pretty much like they always have, though naturally the major version component is now a year and the minor version will march to the month. Here's a real-life first party module version string from our build scripts.
version = "2027.2.0-SNAPSHOT"
... Same story for the platform, these props just feed into build scripts.
# version of Ignition Platform: MAJOR.MINOR.PATCH(-<prerelease>)?
ignition.version.major=2027
ignition.version.minor=2
ignition.version.patch=0
ignition.version.pre=-SNAPSHOT
The -LTS concept is still floating around in conversation and was the original plan until it ran into SemVer constraints.
For platform-module compatibility, I need somebody better versed in requiredIgnitionVersion to weigh in. I think it's "major and minor requiredIgnitionVersion components must match those of the platform," but am not completing following all the nuance in the relevant ticket where they locked this down.
Right. I get that much. Not what I'm asking.
Licensing is keyed to the individual modules' major version (first element of semVer). That gets bumped by IA for platform changes (v7.9→v8.0→v8.1→v8.3→v2027.2→v2028.2→v2029.2). The question is which of those major versions will be used in 2028-LTS?
I want to bump my module major versions for future LTS releases (v8.3→v2028.2→v2030.2), but not for intermediate releases. In other words, do I need to bump my major versions in 2027 to carry through to 2028-LTS, or can I leave them until 2028?
One factor above my pay grade: 2027 might wind up being the next LTS. But let's stick with the original plan, 2028 being the next LTS ... :loading-emoji:
I thought it might be. I already pinged Kevin M for the policy answer--it isn't really a technical question.
Kevin H looped me into this thread, Otherwise I would've stayed out. 
And I'm looking at the the ticket that bears directly on "will your module load cleanly or fault at such-and-such-a-version." Talking policy independent of the processing right now could lead somebody down the wrong path.
Don't think this is too proprietary so pasting QA results to clarify what happens. LTS vs non-LTS (a.k.a. STS) has no bearing on what will happen on module loading AFAIK looking at this and the code that implemented it. You could replace "2027" with "2028" and "8.3.8" with "2027.2.0" and the results would be the same IIUC.
Verification (2027.2.0)
- OK - Module declaring older minor version only 2027.1.0 loads successfully
- OK - Modules declaring newer minor version 2027.9.0 loads as FAULTED
- OK - Same major and minor version 2027.2.0 loads successfully
- OK - Different major versions 8.3.8 load as FAULTED
- OK - Verified across various different modules
Phil, we don't really have a good idea how this is all going to work yet. Things have changed since I last replied here. The next LTS version, the way we're going to label/name versions... sort of unknown right now. I expect the 2027.x.y pattern to remain, but that's about all I know.
Perhaps worthy of a chat at ICC.
I'm not worried about how I declare minimum supported version. The last support for a module file capable of loading across major versions was back in v7.8. (I had modules that worked in 7.5 through 7.8.)
But all of my module major versions are 1.x.y or 2.x.y. The license is compatible across platform changes as long as my module major version doesn't change. Licenses I issued in v8.1 time frames still work in v8.3, because I didn't bump my module major version. I want my licenses to carry forward this way until 2028 LTS, whatever that looks like under the hood. If that LTS will use the 2028.2 semVers for its licenses, then I can kick the can down the road. Otherwise I'll bump my major versions for v2027.2. If not resolved by then, I'll do the latter.
Personally, I’d like the ability to license my modules independently of their versions. I’d rather generate licenses that are tied to a specific platform version.
We use semantic versioning, so our modules major versions are bumped for any breaking changes (irregardless of update importance/size/etc.).
Currently we are issuing license keys with a Maximum Version of 9,999 to get around this, but it would be nice to have more control.
Easy to do yourself, by including a desired key-value pair in the license that corresponds to the allowed platform(s). Have your module file look for the entry corresponding to what it was built for.