When can we expect stable release of oslc4j-client-4.0.0?

I was wondering what is the planned release date for following jars:
oslc4j-client-4.0.0
oslc4j-core-4.0.0
oslc4j-jena-provider-4.0.0
oslc4j-json4j-provider-4.0.0

Thanks,
Vivek

1 Like

Hi Vivek,

We are trying to make sure that we include all the breaking changes we planned to do between major versions. My conservative estimate is a final release around November.

We can make a 4.0.0.M1 milestone release in the meantime if you wish to “pin” your Lyo dependencies.

Cheers,
Andrew

Hello @andrew,
Good day!

Do the Lyo team still considering the same release date for 4.0.0 version?

Thanks.

Regards!
Mario

Hello Mario!

The release is moving a bit slowly, I am not sure which road to take there and users are rather inactive :slight_smile: I would like to make sure the client is in a bit better shape. In particular:

  • I think we should remove OSLC4J from the name, Lyo and OSLC4J are competing as brands and I think it confuses some users. OSLC4JS and OSLC4NET are not part of Lyo anyway. Lyo OSLC4J Client should be simply called Lyo Client.
  • I think we should not duplicate all common code between the old and the new client. Instead, the common old code should be moved somewhere separate or (what I prefer), the old client shall be removed completely. @jamsden is not seemingly ready for a radical move like that.
  • I think domain classes shall be removed in favour of the lyo.domains classes.

I am working on the new reference implementation as part of the work commissioned by the OP PGB and my plan was to make all the necessary changes to Lyo 4.0 as part of that work and to release the final product as Lyo 4.0.

Having said that, as I suggested above, we can make a 4.0.0.M1, M2 etc. releases if you want to have some operational stability for the code you are developing at Koneksys. This way, you will be able to stay on 4.0.0.M1 even if 4.0.0 makes some extra breaking changes for as long as you need.

The reason to retain the old OSLC4J client is because the new one has a different API. We should deprecate the old one and give clients a chance to migrate.

Regarding the name of the client: Lyo is a broad brand identifier, including client and server SDKs, Lyo Designer, reference implementations, samples, etc. that help people develop OSLC applications in Java. OSLC4JClient is a specific part of that broad brand, and identifies exactly what the module is for. This is just good functional naming. Also it follows a common convention. Introducing further API breaking changes for a rename would probably not be worth the cost.

Well, Jad is clearly telling the old users to use 2.4.0 client. It won’t be compatible with JAX-RS 2.0.

Re: OSLC4J. It’s also in the core and everywhere. It’s really not a specific brand but instead a sub-brand for Java SDK. The original idea was to have:

  • Lyo OSLC4J
  • Lyo Perl Client
  • Lyo OSLC4JS
  • Lyo OSLC4NET

As you know, in the end, we deleted the completely obsolete Perl module, both OSLC4JS and OSLC4NET live as standalone projects. This leaves OSLC4J. De-facto, Lyo == OSLC4J these days, except for RIO and other experimental stuff.

Hi @andrew!

Thanks for the answer and the explanation.

It would be great if we could have a 4.0.0.M1 version for using in our current implementation.

Thanks a lot!

Regards!

  • Mario
1 Like

Hello again guys!

Bothering again, is there a release date for the milestone of the version 4? or how can we help?

Thanks.
Regards!

– Mario.

1 Like

Travelling this week. Ricardo should have release permissions too (via Eclipse Jenkins instance).

4.0.0.M1 core & client are released

cc @jad @jamsden

1 Like

Thanks a lot @andrew !

Regards!
– Mario

Nice @andrew! I did not notice! Something for the mailing list?

1 Like

Sure, why not? The release did not even involve any manual steps. I guess we can do the same for every other project except the designer :slight_smile:

This version is for people who want to use 4.0 but are afraid of further breaking changes on the snapshot. So, most people shall remain on the snapshot unless they have a very tight upcoming deadline :slight_smile: