[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] [External] : Re: [jakarta.ee-spec] Semantic Versioning Jakarta APIs
|
On 8/31/21 4:50 PM, Emily Jiang via jakartaee-platform-dev wrote:
Thanks Jean-Louis for your thoughts on this! My comments are inline.
On Thu, Aug 26, 2021 at 6:50 PM Jean-Louis Monteiro
<jlmonteiro@xxxxxxxxxxxxx <mailto:jlmonteiro@xxxxxxxxxxxxx>> wrote:
[..]
I'm not ok with adding an OSGi dependency and I'm not ok with the
impact on the community.
Class retention: even if it's class retention it's still in the
bytecode.
Deployment does not always happen at runtime (Quarkus for example).
And it's not uncommon to use tools like ASM, javasist, or other to
read the bytecode where this annotation could be used for something
specific, seriously impacting portability.
Since package-info is not a proper class, I don't think it will be
processed. I think what you mentioned is for cdi osgi annotation not for
semantic versioning, which was added to get MP Config to be used by
other OSGi specs.
while package-info is not a proper class, some jakarta specs do rely
and/or allow certain things to be there and are reading annotation(s)
from there
Do we want to open that door?
If we add OSGi Version annotation, why don't we add others?
That being said, let's step back a bit.
Let's say we want a semantic versioning in Jakarta for our APIs.
First we would need to discuss and decide on the mailing list.
I would recommend not mixing with the "how to do it?"
On the "how", it looks like all the @Version with OSGi discussion
comes from the tool we want to use (BND).
If the tool does not fit with our requirements, let's use/write
another one.
A tool should help and not be a restriction.
I think we mentioned on the call, we can move these annotations to
Jakarta and go from there.
Do we need them at all? I mean pom knows the version already, why the
version cannot be read from there and reused?
thanks,
--lukas
Throwing a crazy idea to illustrate. Not saying it's good and we
should follow this path.
We have had signature tests with signature definitions for ages.
Why don't we write a tool that does a comparison with a previous
version of the signature definition?
Brainstorming but hope it helps
So far, I have not heard the objections to adopting semantic versioning.
If no one has objections, we can then look into how to get this
implemented and move from there.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
<https://urldefense.com/v3/__http://twitter.com/jlouismonteiro__;!!ACWV5N9M2RV99hQ!acLVUt2ewJuxHAwWuvV2d38P-f83eeFxpifRNFwVtTR0b7Mv_XNaN7_HEQ6msX0zC50$>
http://www.tomitribe.com
<https://urldefense.com/v3/__http://www.tomitribe.com/__;!!ACWV5N9M2RV99hQ!acLVUt2ewJuxHAwWuvV2d38P-f83eeFxpifRNFwVtTR0b7Mv_XNaN7_HEQ6m40wx0uw$>
On Wed, Aug 25, 2021 at 12:15 PM Steve Millidge (Payara)
<steve.millidge@xxxxxxxxxxx> wrote:
My personal view is semantic versioning only focuses on one
aspect of change i.e. breaking changes. It does not provide any
information on whether a new api is significantly enhanced but
without breaking changes and therefore worth a closer look by a
developer. It can also force a "major" release for a minor
incompatibility which may not be relevant to the majority. While
this is intellectually pure it is also anaemic.
Saying that, if we don't fall into the trap of using semantic
versioning for the overall platform then we may get away with it.
Steve
------------------------------------------------------------------------
*From:* jakartaee-platform-dev
<jakartaee-platform-dev-bounces@xxxxxxxxxxx
<mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx>> on behalf
of Emily Jiang via jakartaee-platform-dev
<jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
*Sent:* 24 August 2021 10:14 PM
*To:* jakartaee-platform developer discussions
<jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>>; Jakarta
specification discussions <jakarta.ee-spec@xxxxxxxxxxx
<mailto:jakarta.ee-spec@xxxxxxxxxxx>>
*Cc:* Emily Jiang <emijiang6@xxxxxxxxxxxxxx
<mailto:emijiang6@xxxxxxxxxxxxxx>>
*Subject:* [jakartaee-platform-dev] Semantic Versioning Jakarta
APIs
We discussed in today's Jakarta platform call regarding semantic
versioning Jakarta APIs(see minutes here
<https://urldefense.com/v3/__https://docs.google.com/document/d/1EJ2ilaPhMnQqa3aw6AmwjRbBPGL3_np4uuwklgfqPZI/edit*__;Iw!!ACWV5N9M2RV99hQ!acLVUt2ewJuxHAwWuvV2d38P-f83eeFxpifRNFwVtTR0b7Mv_XNaN7_HEQ6m9EKzJPU$>).
The discussion was positive. Since this impacts all
specifications, we would like to see what others think.
*
*
*Some context on Semantic versioning*
Semantic versioning is to version each individual API package.
Refer this
<https://urldefense.com/v3/__http://docs.osgi.org/whitepaper/semantic-versioning/Semantic-Versioning-20190110.pdf__;!!ACWV5N9M2RV99hQ!acLVUt2ewJuxHAwWuvV2d38P-f83eeFxpifRNFwVtTR0b7Mv_XNaN7_HEQ6mJ1qoSc8$>
white paper to understand semantic versioning. MicroProfile has
been using semantic versioning to version the APIs from the
beginning and it helped the specifications a great deal when
deciding whether to perform a major or minor release. In Jakarta
EE, specs are cautious with backward incompatible changes.
However, no building tool is used to validate whether a
particular spec has introduced such changes.
With semantic versioning, both implementers and end users have a
clear view on what APIs changes are introduced between releases.
If the version for a particular package stays the same between
the releases, it means no changes are introduced for that
package. If major version changes (e.g. the version changes from
1.0 to 2.0), it means backward incompatible changes are
introduced between the releases.
*How to do semantic versioning*
In each API package, you just need to create a package-info.java
with the version number (see an example here
<https://urldefense.com/v3/__https://github.com/eclipse/microprofile-config/blob/master/api/src/main/java/org/eclipse/microprofile/config/package-info.java__;!!ACWV5N9M2RV99hQ!acLVUt2ewJuxHAwWuvV2d38P-f83eeFxpifRNFwVtTR0b7Mv_XNaN7_HEQ6mPRwi7PI$>).
You can also use this package-info to log the javadoc for that
particular package. There are a couple of maven plugins to
process the package version and then do the version comparison.
Again, MicroProfile has the full set up to get it working. It is
just a copy and paste job in the pom.xml when getting semantic
versioning implemented in Jakarta EE specs.
If you have any questions, please feel free to comment here.
--
Thanks
Emily
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx <mailto:jakarta.ee-spec@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec__;!!ACWV5N9M2RV99hQ!acLVUt2ewJuxHAwWuvV2d38P-f83eeFxpifRNFwVtTR0b7Mv_XNaN7_HEQ6mw4GMbq4$>
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!acLVUt2ewJuxHAwWuvV2d38P-f83eeFxpifRNFwVtTR0b7Mv_XNaN7_HEQ6mW6466eY$>
--
Thanks
Emily
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!acLVUt2ewJuxHAwWuvV2d38P-f83eeFxpifRNFwVtTR0b7Mv_XNaN7_HEQ6mW6466eY$
