[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-spec.committee] TCK download directory conventions
|
I still believe we are conflating a need to demonstrate the existence of a compatible implementation in some form for a api spec release review vs making a claim of compatibility for an implementation. I don’t believe we need a permanent TCK result for a release review.
Compatible implementations need persistent representation of their TCK status. We have discussed linking spec to compatible implementations so eventually there is some persistent view of TCK status for various implementations, but this is a separate issue from demonstrating that the TCK associated with the spec is passible.
> On Jul 16, 2019, at 5:24 PM, Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
>
> Then that implies projects may not refer to something volatile -- such as a link to a report on a Jenkins worker node or a "staging" server (unless that report is gong to live "forever"). Should we recommend these results live (or an archive JAR lives) on Maven Central? (I'm not entirely sure if this fits in the T&C of Maven Central, but it would meet the longevity requirement.
>
> On 7/16/2019 1:36 PM, Bill Shannon wrote:
>> Ed Bratt wrote on 7/16/19 9:44 AM:> How long must these results be made available?
>>
>> I believe as long as the release is available, which for Maven Central
>> means forever.
> _______________________________________________
> 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
