| Re: [jakarta.ee-spec.committee] Release records for projects with multiple specifications |
On my first read, it seemed these two answers didn't align.
Wayne says the release record must be created before the Ballot begins. In the case of DI, that would imply this must be done before we can begin a ballot for DI -- (conversely, it can't wait until CDI, which is further down-stream).
Perhaps, Kevin you are saying that splitting the release record into multiple parts is optional.
In the CDI project, there is a Release 3.0, with a date of June 15, 2020. Perhaps this is sufficient and I can just check this off even though the date seems to be the original date and there isn't anything indicating both Dependency Injection and Contexts and Dependency Injection are included -- perhaps that is implied -- and I'm fine with that.
Here is the governance link for CDI project. I'm sorry, I don't know if there's anything specific to check for, other than, it seems to exist and says 3.0 (presumably that's CDI version) and there's no reference to DI (2.0) -- and that wasn't identified in the previous release either.
Wayne, is this all good for DI then?
-- Ed
Another way to do this is to just create separate release records like what I did for the Platform Project: https://projects.eclipse.org/projects/ee4j.jakartaee-platform/governance
We have the top level release record for Jakarta EE 9, but I also created one for Web Profile 9 and Managed Beans 2.0. This is a similar practice as what we do for MicroProfile. I agree with Wayne that this may not be necessary for the actual reviews and EMO processes, but it does help with communicating the intent.
So, if I was reviewing Dependency Injection, I would suggest that they create a separate Release Record for DI 2.0 under the CDI project. We can't state that it's a requirement (per Wayne's note), but it's a nice to have.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date: 07/20/2020 12:14
Subject: [EXTERNAL] Re: [jakarta.ee-spec.committee] Release records for projects with multiple specifications
Sent by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
The release record serves as a means of communicating release plans to the community. As such, it should be created as early in the development cycle as possible. It also serves as the anchor for reviews and EMO processes around reviews and must be created before we start the ballot.
Release records are for projects. As such, a single release record is sufficient for a single project that is releasing multiple specifications at the same time. The description field in the release record should be used to describe the nature of the release (e.g., list the specification releases included).
Wayne
On Sat, Jul 18, 2020 at 12:52 PM Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
Hi,
In the Specification committee Operations Guide, under the section "Creating a Final Specification," step 8 indicates that a formal release record must be created.
I'm currently reviewing Dependency Injection (wave 1) which is included in the Context and Dependency Injection project. Presumably, a release record won't be created until the CDI spec (wave 3) is readied for release.
I presume this is okay, but could someone confirm?
This implies that all the formal EMO and PMC work won't be done, before this specification has completed its ballot. Assuming this is accptable, will these notifications (for CDI) need to include references for both DI and CDI? (I think a consequence of this is that all the EMO and PMC validation work will be done after the DI ballot has been completed. I don't know if that is acceptable, or not.)
Thanks,
-- Ed_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
--Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
Join us at our virtual event: EclipseCon 2020- October 20-22_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________ jakarta.ee-spec.committee mailing list jakarta.ee-spec.committee@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee