Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec] Major vs minor version update for the Plan Reviews

I completely agree with Kevin's position.
It's best practice for software engineering.
When it comes to technical software specifications version numbering, especially at the component level, Software Engineering needs to take precedence over Marketing.

Best regards,
Dan

Dan Bandera
(512) 286-5228
Program Director, Blockchain, Istio, Java technologies, Node.js
IBM Open Technologies, Austin, Texas; OSGi Laureate;
Interim Chair Eclipse OSGi Working Group Steering Committee



Inactive hide details for "Kevin Sutter" ---2021/04/28 03:31:07 PM---Hi, As I either mentor or review the Plan Reviews for the "Kevin Sutter" ---2021/04/28 03:31:07 PM---Hi, As I either mentor or review the Plan Reviews for the upcoming Jakarta

From: "Kevin Sutter" <sutter@xxxxxxxxxx>
To: "Jakarta EE Specification Community Discussions" <jakarta.ee-spec@xxxxxxxxxxx>
Date: 2021/04/28 03:31 PM
Subject: [EXTERNAL] [jakarta.ee-spec] Major vs minor version update for the Plan Reviews
Sent by: "jakarta.ee-spec" <jakarta.ee-spec-bounces@xxxxxxxxxxx>





Hi, As I either mentor or review the Plan Reviews for the upcoming Jakarta Specifications, I am questioning some of the major version updates. Per semantic versioning, we should be limiting the major version update for breaking API changes -- ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hi,
As I either mentor or review the Plan Reviews for the upcoming Jakarta Specifications, I am questioning some of the major version updates. Per
semantic versioning, we should be limiting the major version update for breaking API changes -- not just because we have "too many changes for a minor release".

I will be challenging all of these that I see, but I also ask the rest of the Spec Committee to also help monitor this situation. In the
EFSP we determined that we would encourage the use semantic versioning for the individual Specifications, but we couldn't require it. (The Platform and Profile versions could be an exception to the rule.)

One example that I came across is the JSONB 3.0 Plan Review:

https://github.com/jakartaee/specifications/pull/348

Although the author did an excellent job of highlighting the changes proposed for this release, I didn't see anything that caused an incompatible change. Thus, I am challenging the use of a major version update to 3.0 instead of just increasing the minor version to 2.x. At the end of the day, each Spec Project can decide for themselves, but we should encourage semantic behavior for APIs.


I'm going to post this to the public Spec mailing list since it was a wider audience and this discussion/observation shouldn't be limited to just the Spec Committee (imho). Thanks!

---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn:
https://www.linkedin.com/in/kevinwsutter

Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec




Back to the top