Project

General

Profile

Actions

Support Request #8232

closed

ADTF plugin/filter versioning and migration to new version questions

Added by hidden over 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Normal
Customer:
BOSCH
Department:
Requester's Priority:
Normal
Support Level:
2nd Level
Resolution:
No Customer Feedback
Product Issue Numbers:
Affected Products:
Platform:
Windows 10 64bit
Topic:
ADTF::Common
FAQ Links:

Description

Supportanfrage

I would like to ask for advice/help regarding the ADTF version 3.3.3.
We are building a system based on this version for quite a while and now emerged a need for the proper versioning of our filters. I checked the versioning macros in ADTF 3.3.3 but I could not even compile. We found the problem inside "adtf_version_customer" struct and in the ADTF_PLUGIN_VERSION and the ADTF_ADDITONAL_VERSION_TYPE macros.
What would you recommend to use instead of this (since this is not working)? Is there any alternative beside the dll VERSIONINFO or creating a dummy property? Currently a ADTF version change is not possible since the ADTF 3.3.3 is not compatible with 3.6.1 and multiple teams are working with this. Moving this many people could take months…

My other question would be that even if we would like to move to the new ADTF version
  • Would it be a good idea?
  • What are the responses from other teams?
  • What are the plans for future releases and patches?
  • Could we expect similar problems with it?
    I know it is hard to answer a question like this but when could we expect a stable release, which will worth the time to move?

Lösung

I would like to ask for advice/help regarding the ADTF version 3.3.3.
We are building a system based on this version for quite a while and now emerged a need for the proper versioning of our filters. I checked the versioning macros in ADTF 3.3.3 but I could not even compile. We found the problem inside "adtf_version_customer" struct and in the ADTF_PLUGIN_VERSION and the ADTF_ADDITONAL_VERSION_TYPE macros.
What would you recommend to use instead of this (since this is not working)? Is there any alternative beside the dll VERSIONINFO or creating a dummy property?

Keep in mind there has been a bug within ADTF 3.3.3, which is fixed in current delivery.
This works fine, just use ADTF_PLUGIN_VERSION instead of ADTF_PLUGIN.
If I extend one of our examples:

#include "demo_code_generation_access_filter.h" 
#include "demo_code_generation_generator_filter.h" 

/// this creates the plugin entry methods and class factories
ADTF_PLUGIN_VERSION("Demo Code Generation Plugin", myversion, 0, 8, 15,
            cCodeGenerationDataGenerator,
            cCodeGenerationDataAccess);

And regenerate the plugin description,

you will see in current Configuration Editor the exported and set customer version:

Currently a ADTF version change is not possible since the ADTF 3.3.3 is not compatible with 3.6.1 and multiple teams are working with this. Moving this many people could take months…

The ADTF versions are definetly binary and code compatible along the whole ADTF 3 major version.
You can just use your binaries without recompiling within in the new ADTF version and it will work fine.
You can also recompile your code as well.

What do you mean by not compatible ?

Maybe your implementation is not explicit. Idea:
That means, you are using an cFilter (when you implemented was version namespace ::ant), with ADTF 3.5 there comes a new more helpful and convience Filter API (have a look at our guides and examples), but this is ::flash.
As long as you are using ant::cFilter explicit, your old implementation will work, but if you are using only cFilter it will be resolved to flash::cFilter and not work.
Also your trigger functions must still work, I guess only a namespace clash.
This could be an error, but only if you try to compile. If you are using binaries, everything will work (same as whole ADTF 2.x major version, ADTF is code and binary compatible through a major version).

But you have not to recompile, just yuse your old binaries and only imlement new ones with new Filter SDK, you will love.
If you are using trigger functions, they will be deprecated.
Also if you have problems with ADTF 3.3.3 we won't patch, there are so many good things, features and patches since ADTF 3.5

My other question would be that even if we would like to move to the new ADTF version
Would it be a good idea?

Definetly, yes, at least ADTF 3.5 (new and easier Filter SDK), we would recommend 3.6.x (tool redesign scripting, and stuff, just have a look at the release notes)

What are the responses from other teams?

Great about new Filter SDK

What are the plans for future releases and patches?

The main topics are publish subscribe for multiplexed data
SOME/IP
tooling automazation
more scripting filters
distributed system setups and comunication

for more details, please refer to your customer responsible (Roland Herrmann)

Could we expect similar problems with it?

There are no problems for migration

I know it is hard to answer a question like this but when could we expect a stable release, which will worth the time to move?

ADTF 3.5.0/3.6.x is much more stable than older releases


Files

version.png (77.9 KB) version.png hidden, 2019-08-30 15:39
2019-09-02_08h20_41.png (27.9 KB) 2019-09-02_08h20_41.png hidden, 2019-09-02 08:56
2019-09-02_08h22_25.png (28.4 KB) 2019-09-02_08h22_25.png hidden, 2019-09-02 08:56
2019-09-02_08h27_55.png (27.5 KB) 2019-09-02_08h27_55.png hidden, 2019-09-02 08:56
2019-09-02_08h28_22.png (29.4 KB) 2019-09-02_08h28_22.png hidden, 2019-09-02 08:56
2019-09-02_08h29_44.png (25.9 KB) 2019-09-02_08h29_44.png hidden, 2019-09-02 08:56
2019-09-02_08h29_54.png (25.2 KB) 2019-09-02_08h29_54.png hidden, 2019-09-02 08:56

Related issues

Related to Public Support - Support Request #8420: EBPRODUCTSUPPORT-4827 [EB Internal] ADTF 3.5 macro ADTF_PLUGIN_VERSIONClosedActions
Related to Public Support - Support Request #10807: Filter revision versioning in ADTF 3.xClosedActions
Actions

Also available in: Atom PDF