| Re: [jakarta.ee-spec.committee] Release records for projects with multiple specifications |
Thanks Scott.
It looks better now. I'll defer to Wayne (and/or others) since
I'm not very familiar with how this Governance material is used.
Should we ask all Specs. to use Sept. as the release date, or should they try to use the date of their respective target wave?
-- Ed
That release plan is the boilerplate plan we agreed to use for all EE 9 projects that were not making API changes, only the javax -> jakarta change. The date is from the original estimate. I assume that every release plan date is now obsolete and needs to be updated. I have added the same DI/CDI subproject verbiage as used with the EE 8 release and updated the release date to Sep 15 2020.
On Mon, Jul 20, 2020 at 3:39 PM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:
The date on the Jakarta CDI 3.0 release is bogus and needs to be updated.
I would prefer to see something in the description that describes what the release involves. If it includes DI, then IMHO that should be indicated here. This is no different from what I'd expect (both as an EMO and PMC representative) for any other project: a concise description that tells me the key features of the release. In the case of a specification project, the key features are the names and version number of the specifications included in the release.
If a project team wants to split them up and have separate release records, they're more than welcome to do so. In general, we've done this in the past with Eclipse MicroProfile because MicroProfile releases individual components on separate schedules.
HTH,
Wayne
On Mon, Jul 20, 2020 at 4:14 PM Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
_______________________________________________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
On 7/20/2020 12:49 PM, Kevin Sutter wrote:
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
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