Re: [jakarta.ee-spec.committee] Going backwards with the content on http

["Kevin Sutter" <sutter@xxxxxxxxxx>]

I'm seeing a few
automated PR checks that are "failing" with our pre-deployment
steps...  Maybe these are a known condition.  You can see some
of the check fails via this PR:
https://github.com/jakartaee/specifications/pull/19

I discovered that
the _index.md file had an incorrect TCK link, so I corrected it before
attempting to merge.  I've done a similar change for the platform,
web profile, and this managed beans PR.  When I update my pending
branch with these minor updates, I am getting the messages as logged in
PR #19.  I am waiting for Bill to approve his review comments before
merging this one.  The other PRs with these type of messages, I just
went ahead and merged them.

I trust these
are related to our staging processing and shouldn't be too concerned with
the messages?  That is, we should go ahead with our merges?  Thanks.

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



From:
       Bill
Shannon <bill.shannon@xxxxxxxxxx>
To:
       Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>,
Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>
Date:
       09/06/2019
09:53 PM
Subject:
       [EXTERNAL]
Re: [jakarta.ee-spec.committee] Going backwards with the content on https://jakarta.ee/specifications/?
Sent
by:        jakarta.ee-spec.committee-bounces@xxxxxxxxxxx

---

Wayne Beaton wrote on 9/5/19 7:46
PM:
> Note that I noticed that the breadcrumbs are rendered with absolute
URLs;
> clicking on an entry will take you to the production site.
Ya, I was tripped up by that.  Is that fixable?

> FWIW, the production site is operating as designed and as I described.
That
> some of the specifications were rendering was due to the value in
the date
> field being in the past. When I changed them to September 10/2019,
they were
> removed on the next deployment. I believe that there was some consensus
that
> we wanted to keep information about specifications off the production
site
> until after they were released. Based on this experience, we may want
to
> change this.
I don't see any problem with putting them on the public web site after
they've
actually been approved, even if it's in advance of the platform release
containing them.

> I envision that that the metadata at the top of each of the specification
> files will be valuable (and possibly expanded at one point); we might,
for
> example, generate some kind of data file out of these files. So, having
a real
> date of release here feels like something we want to have. Hugo actually
uses
> the "date" (and "publishDate") fields. We could
instead create our own
> "releaseDate" field and either put a different value in
the date field, or
> just remove the date from the header and render additions as they
come
> (regardless of release date).
>
> I'm thinking that this may be a topic for our retrospective.
>
Agreed.

_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee