[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-spec.committee] Publish Date for the Specification PRs
|
Yeah, you're both
right. I was over-thinking this aspect. We'll just need to
ensure a "proper" date is specified when we merge these PRs.
Thanks for the discussion!
---------------------------------------------------
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/kevinwsutterFrom:
Scott
Stark <sstark@xxxxxxxxxx>To:
Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>Date:
07/15/2020
09:57Subject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] Publish Date for the Specification
PRsSent
by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
Right, the PR should not be merged until
it is approved, so the date should be the expected date of the final ballot
completion or before. I don't see a need to future date the specs for platform
release.On Wed, Jul 15, 2020 at 9:51 AM Ivar
Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>
wrote:On Wed, Jul 15, 2020 at 4:31 PM Kevin
Sutter <sutter@xxxxxxxxxx>
wrote:Ivar,
My concern is that a date might be chosen before the ballot is complete...
If we post a Final Specification and all related artifacts before the ballot
successfully passes, then we could be in a bad state...
The PR shouldn't be merged before the
ballot ends anyway, so I don't think that is an issue. I am more concerned
about specs not showing up due to the date being set tool long in the future. I am not advocating
that all individual Specs have to line up with the Platform. Far
from that. I just don't want to accidentally be publishing something
before a successful ballot.
---------------------------------------------------
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: Ivar
Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>
To: Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date: 07/15/2020
03:00
Subject: [EXTERNAL]
Re: [jakarta.ee-spec.committee] Publish Date for the Specification
PRs
Sent by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
Hi,
As Kevin points out, the date in the index file is the "publish
date" for the document. That means if you put a date forward in
time, the page will not be visible until that date has passed. I know the
naming sucks, but I think the template used was the same that is used for
news articles.
My counter-proposal:
So, each specification project should choose whatever date they want this
particular specification version to be visible in the specification
list [1] on the web page. It does not need to be the same for all specifications.
In fact, it shouldn't be the same for all specifications as specification
A may very well be final and available a long time before it is included
in the platform spec.
Ivar
[1] https://jakarta.ee/specifications/
On Wed, Jul 15, 2020 at 12:45 AM Kevin Sutter <sutter@xxxxxxxxxx>
wrote:
Hi,
This question came up while I was reviewing Scott's PR for Bean Validation:
https://github.com/jakartaee/specifications/pull/222#discussion_r453878981
What [date:] should we be putting into the _index.md file for any of these
final Specification PRs? This field signals what date to allow the
information to be published. This way, we can approve and merge the
PRs prior to the Release date and then let Hugo make the information public
according to the [date:] field.
Here's my proposal:
Initially enter the final (proposed) date for Jakarta EE 9: 2020-09-16
When the ballot is successful, as part of updating this _index.md file
with the ballot results, enter the date the ballot completed. I understand
that this puts some emphasis on the ballot being properly registered in
a timely manner, but that's probably okay to have that pressure.
If we want to be extremely safe of not accidentally pre-publishing something,
maybe we should use 2020-12-31 as the initial [date:] field? We will
release Jakarta EE 9 sometime this year, won't we???
Let's discuss via email before the Spec Committee call next week -- which
I will not be able to attend since I am on vacation... :-) Thanks!
---------------------------------------------------
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
_______________________________________________
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
-- Ivar
Grimstad
Jakarta
EE Developer Advocate | Eclipse
Foundation, Inc.
Community.
Code. Collaboration.
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
-- Ivar
Grimstad
Jakarta
EE Developer Advocate | Eclipse
Foundation, Inc.
Community.
Code. Collaboration.
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