# Mender-client 4.x compatibility with v2 artifacts

**URL:** <https://hub.mender.io/t/mender-client-4-x-compatibility-with-v2-artifacts/6840>\
**Category:** General Discussions\
**Tags:** yocto, mender-client\
**Created:** [May 21, 2024, 1:13pm UTC](https://hub.mender.io/t/mender-client-4-x-compatibility-with-v2-artifacts/6840 "2024-05-21T13:13:50Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![sabelsen](https://avatars.discourse-cdn.com/v4/letter/s/f04885/32.png) [@sabelsen](https://hub.mender.io/u/sabelsen)\
**Post date:** [May 21, 2024, 1:13pm UTC](https://hub.mender.io/t/mender-client-4-x-compatibility-with-v2-artifacts/6840/1 "2024-05-21T13:13:50Z")

</div>

I have two questions concerning the compatibility between mender-client 4.x and artifact version 2:

- Assuming an upgrade from Yocto Dunfell (mender-client 2.x) to Scarthgap (mender-client 4.x) with a v2 artifact. The v2 artifact is programmed using mender-client 2.x. Subsequently, can the v2 artifact be committed with mender-client 4.x?

- Is there any way a v2 artifact can be used with mender-client 4.x at all? If no, why was this legacy support removed?

---

<div class="post-metadata">

**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\
**Post date:** [May 22, 2024, 8:07am UTC](https://hub.mender.io/t/mender-client-4-x-compatibility-with-v2-artifacts/6840/2 "2024-05-22T08:07:41Z")

</div>

Hi @sabelsen,

Mender Client 4.0 only supports Artifact Format 3.0. The legacy format has been removed as the Client 3.x family has been the officially supported one for many years now, and we took the rewrite opportunity to slim down the codebase.

Given your situation, what is your actual concern? You want to upgrade from `dunfell` to `scarthgap`, I presume. As the artifacts are actually created by `mender-artifact`, you also can generate a V2 artifact in a `scarthgap` build by setting `MENDER_ARTIFACT_EXTRA_ARGS` (see [Variables | Mender documentation](https://docs.mender.io/operating-system-updates-yocto-project/variables#mender_artifact_extra_args)) accordingly. This can then be deployed to a fleet currently running legacy V2.0 clients.

Greets,  
Josef

---

<div class="post-metadata">

**Author:** ![sabelsen](https://avatars.discourse-cdn.com/v4/letter/s/f04885/32.png) [@sabelsen](https://hub.mender.io/u/sabelsen)\
**Post date:** [May 22, 2024, 9:04am UTC](https://hub.mender.io/t/mender-client-4-x-compatibility-with-v2-artifacts/6840/3 "2024-05-22T09:04:00Z")

</div>

Thanks for your reply!

In general, my concern is about compatibility.

Broadly speaking, our fleet is running sumo, dunfell and kirkstone. We can upgrade or downgrade between them with the support of V2 artifacts. Unfortunately for us, we do also support software downgrading, and that is a use-case we have to consider. Scarthgap now introduces a break in compatibility without the support for the legacy format. I would assume we can upgrade to scarthgap with a V2 artifact (and commit it through ‘mender-update commit’). Downgrading from scarthgap means creating V3 artifacts for dunfell and kirkstone, but this will not work for sumo as its mender-client does not support V3.

The above introduces some new constraints and distribution of upgrade/downgrade instructions to our customers. It is doable but not optimal.

---

<div class="post-metadata">

**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\
**Post date:** [May 22, 2024, 10:13am UTC](https://hub.mender.io/t/mender-client-4-x-compatibility-with-v2-artifacts/6840/4 "2024-05-22T10:13:41Z")

</div>

Hi @sabelsen,

Well, alternatively you can forward port Mender Client 2.x to scarthgap, or extend Client 4.x with support for Artifact Format V2. Or, as you said, create more specific artifacts.  
Software maintenance often involves various tradeoffs and the “explicitly support downgrades” path is one we decided to not prioritise, as it is rarely needed and in most circumstances a bad idea to roll out unmaintained software with known vulnerability (such as `sumo`).

Sorry I don’t have news more suited to your requirements.

Greetz,  
Josef