Kinetic's Transition to Monthly CI/CD Releases - what is your opinion

Some of our contracts are so old they are perpetual with no right to negotiate with contractually limited YoY cost increases :wink:

Either way people on prem with the 5 year contract train a 10% YoY will still be significantly cheaper for years that moving to the cloud and paying SaaS cost (I have spoken to other companies using Kinetic about his). Most on prem paid alot upfront with maint tagged at 20% of the original cost. The cloud migration ‘deal’ was a slap in the face too BTW. Worked out CHEAPER to stay on prem until 2030 than move now.

OK… under the " :safe_harbor: Safe Harbor :safe_harbor: " lets talk about a few new CI/CD features that are planned for sometime between now and 2027.100… under our old rules, all of these features would have to wait until the annual release. Note that this is NOT final… some of these might change to 2027.100 once we finish the development and find out that it cannot meet our monthly backward compatible requirements.

  1. AP Reconciliation Tracker will add a NEW Tracker that allows you to reconcile your AP to the GL. This is NEW… it is backward compatible. If you choose to not open it, you would never know it was there. If you take the upgrade, it will be there, and you can start using it BEFORE 2027.100
  2. Part Quantity Tracker to have Context menu within the Part field - This is a simple right click to get to things from the part number field.
  3. AUoM - Add Required Number of Pieces on the Issue Material screen this is a display thing… we will show the number of required pieces for an AUOM part when picking. No functionality change… just a display.
  4. Bank Statement-Ability to print the oustanding items - adding the ability to REPRINT something that before, you could not do.

BUT ALSO… we have several ideas that we cannot put into a monthly release, becuase they are not backward compatible. They would either break your current customizations, or would be too drastic of a change:

  1. Improve Customer Part Cross Reference Search - we wanted to put this into a monthly release… but because of the poor initial screen design, any change to improve it would break anyone’s customization that they created within this screen. we are having to do a redesign of the first page to create a much better user experience.
  2. Allow Cycle Count Periods to Cross Calendar Years This change is simply too invasive to do on a monthly cycle and will wait until 2027.100
  3. Cash Receipt Entry - Multiple GL accounts for misc payments - Again, this is a significant change to a screen. Even though most (if not all) of you dont customize this screen, there might be a couple of you that have customized it, and if you did, this would break your customizations, so it imediatly disqualifies it for a monthly upgrade and into the annual release.

A clarification may help here…

We are not taking 2026.100, accumulating a year’s worth of changes, and then packaging all of that into 2027.100 as a giant rollup.

Instead, think of the 2026 code line as a continuously evolving main branch. Throughout the year, we are continually adding backward compatible changes to the software. At the end of the year, new infrastructure, API changes, screen updates, schema changes, and feature enablement work are added to that branch which then becomes evolves into 2027.100.

At that point, 2027.100 again splits into two paths:

  • The current release branch, which continues forward into 2027.101, 2027.102, and so on.
  • The long-term branch, which remains on 2027.100 and only receives maintenance and approved updates.

Internally, we often describe this as a release train model.

You can choose between two trains:

  • The short-term release train
  • The long-term release train

If you are on the long-term train, you only stop at major annual releases like 2026.100 and 2027.100. That means you receive new capabilities in larger batches once per year, and only receive maintenance fixes.

If you are on the short-term CI/CD train, the train stops every month. You pick up smaller sets of new functionality continuously instead of waiting for the annual release. In addition, you will also receive monthly maintenance fixes. Features arrive faster, adoption happens incrementally, and users have more time to absorb and operationalize changes as they appear.

So, both trains receive maintenance updates but only short gets enhancements. How will the releases look then?

Short-term: 2027.100, 2027.101, 2027.102, …
Long-term: 2027.100, 2027.100.1, 2027.100.2, …

ALMOST exactly right… except the first release of 2027 typically starts with patch 3.. so..

Short-term: March:2027.100 (Same as 2027.100.3), April: 2027.101, May: 2027.102, …
Long-term: March: 2027.100.3, 2027.100.4, April: 2027.100.5, .6, May: .7, .8 …

Except, we can’t choose, not really lol.

Hopefully this is taken in the positive spirit that’s intended.

Regardless of the train you take, the increased release schedule has a lot of us a little shook up at the possibility of more frequent derailments regardless of reason (fixes, features or otherwise).

That being said…if the CI/CD process incorporates more thorough pre-release testing and QC…then it’s a step in the right direction.

Unfortunately we’ve become more than a little anxious with how things have gone in recent times…and a fear of the unknown is worse than fear of the known.

Except, you can… Find out more at Insights. (:safe_harbor: Safe Harbor :safe_harbor:)

Does anyone have a link to the recording of this? I haven’t really been able to comprehend what is and isn’t happening based on the number of questions people have posted here in response to watching the webinar. It seems like more clarification is needed, but I haven’t actually watched the webinar myself so and should probably do that first.

Does anyone have the link to this?

Thanks for the link Kevin.

My two cents :

  1. I always enjoy hearing @timshuwy present- there’s something calming about it, he could be delivering the worst news and yet, you’re still calm.
  2. It seems like this is what we’ve been asking for- so long as :safe_harbor: the features introduced on the public cloud track are truly backwards compatible with the feature release before it- so we aren’t having to re-work every one of our customizations.
  3. Maybe I’m misunderstanding, but in flex we can choose to take minor updates and/or monthly releases altogether, is that what everyone else heard/saw??
  4. Even if item number 3 turns out to be we cannot choose to ignore monthly features and patch updates on public cloud (starting in 2027.100), we still get 4+ months to test it/self upgrade from what I’m understanding from this slide I’ve been looking at for 20 minutes while typing all this.
  5. Still confused about whether we can choose to opt out of the feature releases on public cloud like we could with the patches/maintenance if we were fully self-managed across prod, pilot, additional environments… it sounds like no?
  6. If a breaking change gets called out via testing, will it get moved accordingly, instead of introduced with some workaround or no workaround at all? I heard a question that asked if they could not accept a feature if something broke something, but then I’m thinking- we just said we wouldn’t receive anything that broke something… so I feel like the answer to my question here is “yes, we will re-work the broken feature and introduce it at a later date… but I have to imagine that’s hard to commit to if the feature was far reaching in a lot of other business objects, etc.”.
  7. Well done answering Q+A questions.
  8. Overall, the goal to make the disruption to the business as minimal as possible and introduce a faster time-to-value for new features seems to align with so much of what we have all been talking about in our own ways across several of the threads on the forum so this seems like a giant improvement. The “not introducing features that break things” is a gamechanger for me as well as the amount of features introduced being lower going forward makes it all more manageable. There is nothing worse than having a broken ERP because of a feature you never needed in the first place.
  9. That was more than two cents, but the webinar was rich. Really excited for this change.

That’s what the site maintenance was for! Makes sense now :joy:

somewhat off-topic but just want to say happy to see a few AUOM ideas ‘In Development’.

Hoping the few involving Number Of Pieces are a tad more than just display-only. I mean displaying QtyRequired in pcs is better than nothing but when issuing a material, we need to enter Quantity Issued in pcs as well.

EDIT: nevermind me. It’s there. Hedge>

:grin:

Yesterday, there was a thoughtful conversation about CI/CD, and now Progressive Delivery, between Gergely Orosz (The Pragmatic Engineer) and Robert Erez (currently Octopus Deploy, formerly pre-Microsoft Skype)

This is my opinion summed up in the recent Kinetic 2025.2.20 update from 2025.2.12.

We updated and Count Entry stopped working due to a bug in a where clause. So far Epicor haven’t issues a fix. Luckily the emergency break was pulled and we put the screen back to Classic to get us through our stock takes. WE then had to crate a BPM to fix the where clause removing the double '. Support were literally told what the issue was and sent us an unrelated datafix. Again we still don’t have an official fix. Had I not had an indutrious IT team and/or Classic we would litterally not be able to do stock takes.

We put off updating for a reason.

We literally have a group of BPMs called BugFixes as we have been doing this kind of fix for almost 20 years.

Mark, I’d encourage everyone to really… okay you deleted it haha. I’d encourage everyone to watch that webinar again and really study what they said.

I was taking a ton of notes trying to keep it all straight because I think they were also trying to keep it straight, but at the end of it I understood that major releases like this were going to be disruptive and break things, everything else wouldn’t… I may have to rewatch it myself.

I post hoped by accident was replying to something on the other thread where it was pertinent but its less so here.