Eclipse BIRT designer backward compatibility issue

[cchai-newtrek]

Is your feature request related to a problem? Please describe.
Initially I installed Eclipse BIRT plugin designer v4.20.0, and after that my Eclipse auto update and the BIRT is upgraded to v4.23.0, but my BIRT runtime in production is still v4.20.0.
When I use the new v4.23.0 designer to edit the rptdesign file, it will auto change the file createdBy attribute

from
<property name="createdBy">Eclipse BIRT Designer Version 4.20.0.vxxxxxxx</property>
to
<property name="createdBy">Eclipse BIRT Designer Version 4.23.0.vxxxxxxx</property>

when I deploy the updated rptdesign file to the runtime, it fails to run as the runtime is v4.20.0 but the rptdesign is v4.23.0, so is it possible to give us an option to keep the original version number without update it?

I need to rollback this createdBy attribute every time I updated the rptdesign file.

Describe the solution you'd like
Is it possible to give us a new attribute like "doNotUpdateCreatedBy" Y/N to keep the original version number of the rptdesign file so that the designer will not update the "createdBy" attribute?

[hvbtup]

The version is incremented for a reason:
New features or bugfixes which require changes in the XML model.
It will not be incremented if a new BIRT release doesn't change the XML model.

With a reasonable amount of development work, your proposed cannot be made to work.

IMHO a more useful solution would be to add a System property which tells the runtime to just ignore all XML tags which it doesn't understand when reading *.rptdesign / *.rptlibrary files, and just issue a warning message if it finds one, and maybe an extra warning when the reports version is higher than the runtime version.
However, this could hide bugs like when (many years ago) the implementation for de-/serialization of aggregate properties changed or when some default values change etc.

[merks]

In other words, this is highly unlikely to happen unless the people who want the feature contribute the solution or fund someone to do it. So over time, it's like to be returned as "not planned"...

[cchai-newtrek]

The version is incremented for a reason: New features or bugfixes which require changes in the XML model. It will not be incremented if a new BIRT release doesn't change the XML model.

With a reasonable amount of development work, your proposed cannot be made to work.

IMHO a more useful solution would be to add a System property which tells the runtime to just ignore all XML tags which it doesn't understand when reading *.rptdesign / *.rptlibrary files, and just issue a warning message if it finds one, and maybe an extra warning when the reports version is higher than the runtime version. However, this could hide bugs like when (many years ago) the implementation for de-/serialization of aggregate properties changed or when some default values change etc.

yes your solution will be more generalize but in my case it is not possible since my production Java version is 17 and my BIRT runtime is v4.20.0 which I cannot casually update.

and your solution will need a new version (unless BIRT will provide a patched version for v4.20.0 runtime) which the most update BIRT runtime is run on Java 21 which I may not able to update it in my production environment.

[hvbtup]

Then I recommend to just "downgrade" the version number of your *.rpt* files automatically in your build system. It's just search and replace, after all.

And of course it's not the best idea to use a different BIRT version for developing than at runtime.
That said, I do it as well, but the other way round. I mostly use BIRT 4.2.1 with Java 8 for development and much newer versions at runtime.

If you're using a newer BIRT version for development than at runtime, you may end up using new features which then ofc don't work at runtime.

[cchai-newtrek]

Then I recommend to just "downgrade" the version number of your *.rpt* files automatically in your build system. It's just search and replace, after all.

And of course it's not the best idea to use a different BIRT version for developing than at runtime. That said, I do it as well, but the other way round. I mostly use BIRT 4.2.1 with Java 8 for development and much newer versions at runtime.

If you're using a newer BIRT version for development than at runtime, you may end up using new features which then ofc don't work at runtime.

Yes thx for your advice, seems this is the only option I can have with higher version of designer than the runtime.

I do not want to upgrade my BIRT designer but the Eclipse update force to upgrade it :(