Re: [cross-project-issues-dev] Log4j 1.x vulnerability

[Ed Willink]

Hi

For those needing to update: Orbit now has:

    location="https://download.eclipse.org/tools/orbit/downloads/latest-S"/>
    location="https://download.eclipse.org/tools/orbit/downloads/latest-R"/>


so there is no need to update ever again. Just rebuild.

    Regards

        Ed Willink

On 24/02/2022 02:13, Jonah Graham wrote:

Hi folks,

I have now checked and the EPP packages that have org.apache.log4j now 
have the 1.2.19 reload4j version.


Some progress has already been made on the bugs, so with a bit more 
work we can have the whole simrel free of the 1.2.15 version of log4j.


However, individual projects need to update to the newest Orbit 
version and rebuild. Numerous projects still have the 1.2.15 version 
in their p2 repos.


Thanks,
Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com 


On Wed, 23 Feb 2022 at 12:22, Jonah Graham  wrote:

Hi folks,

The SimRel release will include the reload4j version of the
bundle. Most p2 install resolutions will pull in the reload4j
version.

However it also includes the 1.2.15 version because of some hard
dependencies on the 1.2.15 version (Bug 578940
 Bug 578941
)

When I do the EPP build I will verify/report whether any of the
packages contain the 1.2.15 version.

Jonah


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com 


On Wed, 16 Feb 2022 at 03:04, Dirk Fauth via
cross-project-issues-dev  wrote:

Just as an information for people that did not get the current
status via other channels.

The re-bundled version of reload4j is available in the latest
stable build of Eclipse Orbit.

Logpresso has added handling for the re-bundled variant and
will not detect the vulnerability in its latest version.

Christian Dietrich  schrieb am
Di., 8. Feb. 2022, 17:18:

yes i tried to use the pomDependencies consider features
https://git.eclipse.org/r/c/orbit/orbit-recipes/+/190576

https://ci.eclipse.org/orbit/job/gerrit-orbit-recipes/1782/artifact/releng/repository-all/target/repository/
but i get signing warning and also naming conventions etc
are completely "bogus"

Am 08.02.22 um 17:16 schrieb Ed Merks:


Christian,

I *assume *it is not jar signed but rather only has an
external PGP signature.

Regards,...
Ed

On 08.02.2022 16:48, Christian Dietrich wrote:


is the orginal signing not enhough?
and what about about.html and other eclipse rule foo.

Am 08.02.22 um 16:32 schrieb Matthias Sohn:

I went ahead and pushed the naive addition of reload4j
1.2.19 disguised as bundle org.apache.log4j to Orbit
https://git.eclipse.org/r/c/orbit/orbit-recipes/+/190574
feel free to change this if someone finds out how to
use EBR to only sign the upstream artefact.
-Matthias

On Tue, Feb 8, 2022 at 4:04 PM Dirk Fauth via
cross-project-issues-dev
 wrote:

Well, from my point of view the usage of reload4j
is the only backwards compatible solution.
Unfortunately not for every case, e.g. too strict
version ranges. The solution forward is of course
the usage of a log wrapper to decouple development
from deployment.

Anyhow I don't know how to add a bundle jar signed
and unchanged to Orbit. I am only aware of the
re-bundling via EBR. Doing that will cause a change
in the jar structure that causes for example
logpresso to identify a CVE, although it is fixed.
Which is actually only an issue in the detection.
But that was one of the reasons why I contacted the
reload4j project to change the base to avoid the
re-bundling.

Anyone who knows how to only sign and publish to
Orbit without re-bundling?

Ed Merks  schrieb am Di., 8.
Feb. 2022, 15:54:

Dirk,

Thanks.  That's really great!  It would be
great for this release cycle if it were jar
signed and available from Orbit so that we
could ship it with 2022-03...

There are people who are concerned:


https://www.eclipse.org/forums/index.php/mv/msg/1109656/1849775/#msg_1849775

Though I'm not sure if they would consider the
problem being fixed in 1.2.19 a fact and even
 

Re: [cross-project-issues-dev] Log4j 1.x vulnerability

[Jonah Graham]

Hi folks,

I have now checked and the EPP packages that have org.apache.log4j now have
the 1.2.19 reload4j version.

Some progress has already been made on the bugs, so with a bit more work we
can have the whole simrel free of the 1.2.15 version of log4j.

However, individual projects need to update to the newest Orbit version and
rebuild. Numerous projects still have the 1.2.15 version in their p2 repos.

Thanks,
Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Wed, 23 Feb 2022 at 12:22, Jonah Graham  wrote:

> Hi folks,
>
> The SimRel release will include the reload4j version of the bundle. Most
> p2 install resolutions will pull in the reload4j version.
>
> However it also includes the 1.2.15 version because of some hard
> dependencies on the 1.2.15 version (Bug 578940
>  Bug 578941
> )
>
> When I do the EPP build I will verify/report whether any of the packages
> contain the 1.2.15 version.
>
> Jonah
>
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Wed, 16 Feb 2022 at 03:04, Dirk Fauth via cross-project-issues-dev <
> cross-project-issues-dev@eclipse.org> wrote:
>
>> Just as an information for people that did not get the current status via
>> other channels.
>>
>> The re-bundled version of reload4j is available in the latest stable
>> build of Eclipse Orbit.
>>
>> Logpresso has added handling for the re-bundled variant and will not
>> detect the vulnerability in its latest version.
>>
>> Christian Dietrich  schrieb am Di., 8.
>> Feb. 2022, 17:18:
>>
>>> yes i tried to use the pomDependencies consider features
>>> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/190576
>>>
>>> https://ci.eclipse.org/orbit/job/gerrit-orbit-recipes/1782/artifact/releng/repository-all/target/repository/
>>> but i get signing warning and also naming conventions etc
>>> are completely "bogus"
>>> Am 08.02.22 um 17:16 schrieb Ed Merks:
>>>
>>> Christian,
>>>
>>> I *assume *it is not jar signed but rather only has an external PGP
>>> signature.
>>>
>>> Regards,...
>>> Ed
>>> On 08.02.2022 16:48, Christian Dietrich wrote:
>>>
>>> is the orginal signing not enhough?
>>> and what about about.html and other eclipse rule foo.
>>> Am 08.02.22 um 16:32 schrieb Matthias Sohn:
>>>
>>> I went ahead and pushed the naive addition of reload4j 1.2.19 disguised
>>> as bundle org.apache.log4j to Orbit
>>> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/190574
>>> feel free to change this if someone finds out how to use EBR to only
>>> sign the upstream artefact.
>>> -Matthias
>>>
>>> On Tue, Feb 8, 2022 at 4:04 PM Dirk Fauth via cross-project-issues-dev <
>>> cross-project-issues-dev@eclipse.org> wrote:
>>>
 Well, from my point of view the usage of reload4j is the only backwards
 compatible solution. Unfortunately not for every case, e.g. too strict
 version ranges. The solution forward is of course the usage of a log
 wrapper to decouple development from deployment.

 Anyhow I don't know how to add a bundle jar signed and unchanged to
 Orbit. I am only aware of the re-bundling via EBR. Doing that will cause a
 change in the jar structure that causes for example logpresso to identify a
 CVE, although it is fixed. Which is actually only an issue in the
 detection. But that was one of the reasons why I contacted the reload4j
 project to change the base to avoid the re-bundling.

 Anyone who knows how to only sign and publish to Orbit without
 re-bundling?

 Ed Merks  schrieb am Di., 8. Feb. 2022, 15:54:

> Dirk,
>
> Thanks.  That's really great!  It would be great for this release
> cycle if it were jar signed and available from Orbit so that we could ship
> it with 2022-03...
>
> There are people who are concerned:
>
>
> https://www.eclipse.org/forums/index.php/mv/msg/1109656/1849775/#msg_1849775
>
> Though I'm not sure if they would consider the problem being fixed in
> 1.2.19 a fact and even if its a fact if it would be a fact that matters...
>
> Regards,
> Ed
>
> On 08.02.2022 15:48, Dirk Fauth via cross-project-issues-dev wrote:
>
> Hi,
>
> I got in contact with the reload4j team. They changed the
> Bundle-SymbolicName to org.apache.log4j and fixed several OSGi meta data
> related issues in the meanwhile. Today they published 1.2.19 which should
> work as a drop-in replacement in Eclipse based applications where
> Require-Bundle was used. My local tests worked so far.
>
> That said, re-bundling for Orbit should not be necessary as reload4j
> could directly be consumed via Maven Central.
>
> Just wanted to keep you updated.
>
> Greez,
> Dirk
>
> Ed Willink  schrieb am Mi., 26. Jan. 2022,
> 13:47:
>
>> Hi
>>
>> On 26/01/2022 07:48, Christoph Läubrich wrote:
>> > 

Re: [cross-project-issues-dev] Log4j 1.x vulnerability

[Jonah Graham]

Hi Christian,

I will check if EPP packages contain log4j 1.2.15.

SimRel will contain 1.2.15 in 2022-03 unless the two bugs listed are
resolved in time.

Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Wed, 23 Feb 2022 at 12:27, Christian Dietrich <
christian.dietr...@itemis.de> wrote:

> @Jonah, will you distinguish between "contain" and "pull"
> Am 23.02.22 um 18:22 schrieb Jonah Graham:
>
> Hi folks,
>
> The SimRel release will include the reload4j version of the bundle. Most
> p2 install resolutions will pull in the reload4j version.
>
> However it also includes the 1.2.15 version because of some hard
> dependencies on the 1.2.15 version (Bug 578940
>  Bug 578941
> )
>
> When I do the EPP build I will verify/report whether any of the packages
> contain the 1.2.15 version.
>
> Jonah
>
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Wed, 16 Feb 2022 at 03:04, Dirk Fauth via cross-project-issues-dev <
> cross-project-issues-dev@eclipse.org> wrote:
>
>> Just as an information for people that did not get the current status via
>> other channels.
>>
>> The re-bundled version of reload4j is available in the latest stable
>> build of Eclipse Orbit.
>>
>> Logpresso has added handling for the re-bundled variant and will not
>> detect the vulnerability in its latest version.
>>
>> Christian Dietrich  schrieb am Di., 8.
>> Feb. 2022, 17:18:
>>
>>> yes i tried to use the pomDependencies consider features
>>> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/190576
>>>
>>> https://ci.eclipse.org/orbit/job/gerrit-orbit-recipes/1782/artifact/releng/repository-all/target/repository/
>>> but i get signing warning and also naming conventions etc
>>> are completely "bogus"
>>> Am 08.02.22 um 17:16 schrieb Ed Merks:
>>>
>>> Christian,
>>>
>>> I *assume *it is not jar signed but rather only has an external PGP
>>> signature.
>>>
>>> Regards,...
>>> Ed
>>> On 08.02.2022 16:48, Christian Dietrich wrote:
>>>
>>> is the orginal signing not enhough?
>>> and what about about.html and other eclipse rule foo.
>>> Am 08.02.22 um 16:32 schrieb Matthias Sohn:
>>>
>>> I went ahead and pushed the naive addition of reload4j 1.2.19 disguised
>>> as bundle org.apache.log4j to Orbit
>>> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/190574
>>> feel free to change this if someone finds out how to use EBR to only
>>> sign the upstream artefact.
>>> -Matthias
>>>
>>> On Tue, Feb 8, 2022 at 4:04 PM Dirk Fauth via cross-project-issues-dev <
>>> cross-project-issues-dev@eclipse.org> wrote:
>>>
 Well, from my point of view the usage of reload4j is the only backwards
 compatible solution. Unfortunately not for every case, e.g. too strict
 version ranges. The solution forward is of course the usage of a log
 wrapper to decouple development from deployment.

 Anyhow I don't know how to add a bundle jar signed and unchanged to
 Orbit. I am only aware of the re-bundling via EBR. Doing that will cause a
 change in the jar structure that causes for example logpresso to identify a
 CVE, although it is fixed. Which is actually only an issue in the
 detection. But that was one of the reasons why I contacted the reload4j
 project to change the base to avoid the re-bundling.

 Anyone who knows how to only sign and publish to Orbit without
 re-bundling?

 Ed Merks  schrieb am Di., 8. Feb. 2022, 15:54:

> Dirk,
>
> Thanks.  That's really great!  It would be great for this release
> cycle if it were jar signed and available from Orbit so that we could ship
> it with 2022-03...
>
> There are people who are concerned:
>
>
> https://www.eclipse.org/forums/index.php/mv/msg/1109656/1849775/#msg_1849775
>
> Though I'm not sure if they would consider the problem being fixed in
> 1.2.19 a fact and even if its a fact if it would be a fact that matters...
>
> Regards,
> Ed
>
> On 08.02.2022 15:48, Dirk Fauth via cross-project-issues-dev wrote:
>
> Hi,
>
> I got in contact with the reload4j team. They changed the
> Bundle-SymbolicName to org.apache.log4j and fixed several OSGi meta data
> related issues in the meanwhile. Today they published 1.2.19 which should
> work as a drop-in replacement in Eclipse based applications where
> Require-Bundle was used. My local tests worked so far.
>
> That said, re-bundling for Orbit should not be necessary as reload4j
> could directly be consumed via Maven Central.
>
> Just wanted to keep you updated.
>
> Greez,
> Dirk
>
> Ed Willink  schrieb am Mi., 26. Jan. 2022,
> 13:47:
>
>> Hi
>>
>> On 26/01/2022 07:48, Christoph Läubrich wrote:
>> > Why not using SLF4J in all places and let the user choose the
>> > implementation with their favorite CVEs?
>>

Re: [cross-project-issues-dev] Log4j 1.x vulnerability

[Christian Dietrich]

@Jonah, will you distinguish between "contain" and "pull"

Am 23.02.22 um 18:22 schrieb Jonah Graham:

Hi folks,

The SimRel release will include the reload4j version of the bundle. 
Most p2 install resolutions will pull in the reload4j version.


However it also includes the 1.2.15 version because of some hard 
dependencies on the 1.2.15 version (Bug 578940 
 Bug 578941 
)


When I do the EPP build I will verify/report whether any of the 
packages contain the 1.2.15 version.


Jonah


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com 


On Wed, 16 Feb 2022 at 03:04, Dirk Fauth via cross-project-issues-dev 
 wrote:


Just as an information for people that did not get the current
status via other channels.

The re-bundled version of reload4j is available in the latest
stable build of Eclipse Orbit.

Logpresso has added handling for the re-bundled variant and will
not detect the vulnerability in its latest version.

Christian Dietrich  schrieb am Di.,
8. Feb. 2022, 17:18:

yes i tried to use the pomDependencies consider features
https://git.eclipse.org/r/c/orbit/orbit-recipes/+/190576

https://ci.eclipse.org/orbit/job/gerrit-orbit-recipes/1782/artifact/releng/repository-all/target/repository/
but i get signing warning and also naming conventions etc
are completely "bogus"

Am 08.02.22 um 17:16 schrieb Ed Merks:


Christian,

I *assume *it is not jar signed but rather only has an
external PGP signature.

Regards,...
Ed

On 08.02.2022 16:48, Christian Dietrich wrote:


is the orginal signing not enhough?
and what about about.html and other eclipse rule foo.

Am 08.02.22 um 16:32 schrieb Matthias Sohn:

I went ahead and pushed the naive addition of reload4j
1.2.19 disguised as bundle org.apache.log4j to Orbit
https://git.eclipse.org/r/c/orbit/orbit-recipes/+/190574
feel free to change this if someone finds out how to use
EBR to only sign the upstream artefact.
-Matthias

On Tue, Feb 8, 2022 at 4:04 PM Dirk Fauth via
cross-project-issues-dev
 wrote:

Well, from my point of view the usage of reload4j is
the only backwards compatible solution. Unfortunately
not for every case, e.g. too strict version ranges. The
solution forward is of course the usage of a log
wrapper to decouple development from deployment.

Anyhow I don't know how to add a bundle jar signed and
unchanged to Orbit. I am only aware of the re-bundling
via EBR. Doing that will cause a change in the jar
structure that causes for example logpresso to identify
a CVE, although it is fixed. Which is actually only an
issue in the detection. But that was one of the reasons
why I contacted the reload4j project to change the base
to avoid the re-bundling.

Anyone who knows how to only sign and publish to Orbit
without re-bundling?

Ed Merks  schrieb am Di., 8. Feb.
2022, 15:54:

Dirk,

Thanks.  That's really great!  It would be great
for this release cycle if it were jar signed and
available from Orbit so that we could ship it with
2022-03...

There are people who are concerned:


https://www.eclipse.org/forums/index.php/mv/msg/1109656/1849775/#msg_1849775

Though I'm not sure if they would consider the
problem being fixed in 1.2.19 a fact and even if
its a fact if it would be a fact that matters...

Regards,
Ed

On 08.02.2022 15:48, Dirk Fauth via
cross-project-issues-dev wrote:

Hi,

I got in contact with the reload4j team. They
changed the Bundle-SymbolicName to
org.apache.log4j and fixed several OSGi meta data
related issues in the meanwhile. Today they
published 1.2.19 which should work as a drop-in
replacement in Eclipse based applications where
Require-Bundle was used. My local tests worked so far.

That said, re-bundling for Orbit should not be
necessary as reload4j could directly be consumed
via Maven Central.

Just wanted to keep you updated.

Greez,
Dirk

Ed Willink  schrieb am Mi.,
26. Jan. 2022, 13:47:

Hi

On 26/01/2022 07:48, Christoph Läubrich wrote:
> Why

Re: [cross-project-issues-dev] Log4j 1.x vulnerability

[Jonah Graham]

Hi folks,

The SimRel release will include the reload4j version of the bundle. Most p2
install resolutions will pull in the reload4j version.

However it also includes the 1.2.15 version because of some hard
dependencies on the 1.2.15 version (Bug 578940
 Bug 578941
)

When I do the EPP build I will verify/report whether any of the packages
contain the 1.2.15 version.

Jonah


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Wed, 16 Feb 2022 at 03:04, Dirk Fauth via cross-project-issues-dev <
cross-project-issues-dev@eclipse.org> wrote:

> Just as an information for people that did not get the current status via
> other channels.
>
> The re-bundled version of reload4j is available in the latest stable build
> of Eclipse Orbit.
>
> Logpresso has added handling for the re-bundled variant and will not
> detect the vulnerability in its latest version.
>
> Christian Dietrich  schrieb am Di., 8. Feb.
> 2022, 17:18:
>
>> yes i tried to use the pomDependencies consider features
>> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/190576
>>
>> https://ci.eclipse.org/orbit/job/gerrit-orbit-recipes/1782/artifact/releng/repository-all/target/repository/
>> but i get signing warning and also naming conventions etc
>> are completely "bogus"
>> Am 08.02.22 um 17:16 schrieb Ed Merks:
>>
>> Christian,
>>
>> I *assume *it is not jar signed but rather only has an external PGP
>> signature.
>>
>> Regards,...
>> Ed
>> On 08.02.2022 16:48, Christian Dietrich wrote:
>>
>> is the orginal signing not enhough?
>> and what about about.html and other eclipse rule foo.
>> Am 08.02.22 um 16:32 schrieb Matthias Sohn:
>>
>> I went ahead and pushed the naive addition of reload4j 1.2.19 disguised
>> as bundle org.apache.log4j to Orbit
>> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/190574
>> feel free to change this if someone finds out how to use EBR to only sign
>> the upstream artefact.
>> -Matthias
>>
>> On Tue, Feb 8, 2022 at 4:04 PM Dirk Fauth via cross-project-issues-dev <
>> cross-project-issues-dev@eclipse.org> wrote:
>>
>>> Well, from my point of view the usage of reload4j is the only backwards
>>> compatible solution. Unfortunately not for every case, e.g. too strict
>>> version ranges. The solution forward is of course the usage of a log
>>> wrapper to decouple development from deployment.
>>>
>>> Anyhow I don't know how to add a bundle jar signed and unchanged to
>>> Orbit. I am only aware of the re-bundling via EBR. Doing that will cause a
>>> change in the jar structure that causes for example logpresso to identify a
>>> CVE, although it is fixed. Which is actually only an issue in the
>>> detection. But that was one of the reasons why I contacted the reload4j
>>> project to change the base to avoid the re-bundling.
>>>
>>> Anyone who knows how to only sign and publish to Orbit without
>>> re-bundling?
>>>
>>> Ed Merks  schrieb am Di., 8. Feb. 2022, 15:54:
>>>
 Dirk,

 Thanks.  That's really great!  It would be great for this release cycle
 if it were jar signed and available from Orbit so that we could ship it
 with 2022-03...

 There are people who are concerned:


 https://www.eclipse.org/forums/index.php/mv/msg/1109656/1849775/#msg_1849775

 Though I'm not sure if they would consider the problem being fixed in
 1.2.19 a fact and even if its a fact if it would be a fact that matters...

 Regards,
 Ed

 On 08.02.2022 15:48, Dirk Fauth via cross-project-issues-dev wrote:

 Hi,

 I got in contact with the reload4j team. They changed the
 Bundle-SymbolicName to org.apache.log4j and fixed several OSGi meta data
 related issues in the meanwhile. Today they published 1.2.19 which should
 work as a drop-in replacement in Eclipse based applications where
 Require-Bundle was used. My local tests worked so far.

 That said, re-bundling for Orbit should not be necessary as reload4j
 could directly be consumed via Maven Central.

 Just wanted to keep you updated.

 Greez,
 Dirk

 Ed Willink  schrieb am Mi., 26. Jan. 2022, 13:47:

> Hi
>
> On 26/01/2022 07:48, Christoph Läubrich wrote:
> > Why not using SLF4J in all places and let the user choose the
> > implementation with their favorite CVEs?
>
> Use of SLF4J has been suggested before and so I tried to be a good
> Eclipse citizen. My failed attempts are described in:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=559532
>
> If SLF4J is to be used, can someone please ensure that the platform is
> fit for purpose and that there is a good tutorial on how to do really
> boring logging.
>
> Regards
>
> Ed Willink
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>

Re: [cross-project-issues-dev] +0.0.1 rather than +0.1.0 for OCL, QVTd for 2022-03

[Jonah Graham]

Thanks Ed for the notice.

To anyone depending on OCL please keep in mind that
https://download.eclipse.org/releases/2022-03/ repo is a composite of all
the milestones and that means that the 6.18.0 version will be visible and
installable still. Indeed I expect p2 will likely install the 6.18 version
in preference. Once the M3 release is made at the end of this week, you can
point at the M3 specific release (likely to be
https://download.eclipse.org/releases/2022-03/202202251000/ or similar).

Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Wed, 23 Feb 2022 at 09:05, Ed Willink  wrote:

> Hi
>
> The current work on static operations (and properties) to support custom
> OCL libraries is not sufficiently mature for 2022-03. OCL (and QVTd)
> will therefore release 6.17.1 and 0.28.1 for 2022-03 rather than 6.18.0,
> 0.29.0.
>
> For M3, the 6.17.0 and 0.28.0 releases are re-contributed.
>
> For RC1, 6.17.1 and 0.28.1 will appear with just minor bug fixes.
>
> This change should not affect anyone, apart from Wayne's stats, since
> hopefully nobody has a tight version lower bound.
>
> @Wayne: PMI pages already updated.
>
>  Regards
>
>  Ed Willink
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] +0.0.1 rather than +0.1.0 for OCL, QVTd for 2022-03

[Ed Willink]

Hi

The current work on static operations (and properties) to support custom 
OCL libraries is not sufficiently mature for 2022-03. OCL (and QVTd) 
will therefore release 6.17.1 and 0.28.1 for 2022-03 rather than 6.18.0, 
0.29.0.


For M3, the 6.17.0 and 0.28.0 releases are re-contributed.

For RC1, 6.17.1 and 0.28.1 will appear with just minor bug fixes.

This change should not affect anyone, apart from Wayne's stats, since 
hopefully nobody has a tight version lower bound.


@Wayne: PMI pages already updated.

    Regards

        Ed Willink


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev