|Re: [jakartaee-platform-dev] Releasing api jars to central|
We spoke in the Spec Committee, that for Jakarta EE 10 there are items for improvement and the CI Tools (Maybe not everyone can use whatever they want then eitherO;-) were at least one item.
Maybe we can gather those ideas in some place and allow the few members of the community outside those committees who are also happy to provide Input to do so.
Gesendet von Mail für Windows 10
A compromise could be that a spec's ballot request MUST refer to a CI which is RC (not milestone), and the vendor of the CI confirms somehow that RCs will be publicly archived. Also, we could agree that starting with RC level a CI must never drop support of an API.
I don’t see this as a problem for the release process. The api release process references a specific version of a CI with a reference to the download location. It is a decision of a CI project team whether a later version of their product supports a specification or not. If a CI drops support for an api after api release I don’t see how that invalidates the api release.
The only problem I could see would be if the CI respan the same version number and dropped the api support however I don’t believe that is the case here. GlassFish 6.0.0-RC2 is pushed to maven central for example. We should ensure that any version of a CI, whether final or not, used to finalise an api release is on a public download site and remains there.
Requiring a CI to be final to release a final api introduces a chicken and egg problem which becomes incredibly difficult to coordinate when you reach the platform project.
The problem is that milestones are volatile. What happens in case the final product drops support of the API between milestone and release candidate to postpone to later release of the product? Then the referenced CI would not even be a CI anymore, hence we end up with a CI-less spec?! Due to that, specs should never have non-final products as CIs.
My original question was more about holding back for a marketing big reveal rather than a process question. However the process questions are interesting.
My understanding is the rationale behind the requirement for a Compatible Implementation in the EFSP is to ensure that the api is implementable and the TCK is usable. There’s no requirement or any real problem if the Compatible Implementation used for api release is not “final”. Requiring a “final” CI would tie the api release to an independently controlled product roadmap which I think would be a bad thing.
Possibly not the spec APIs, but at least the CIs. For example, Jakarta REST went into a ballot referring to a CI that was itself an M6 only (not even an RC).
Von:jakartaee-platform-dev-bounces@xxxxxxxxxxx [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] Im Auftrag von Scott Stark
The artifacts of a specification are staged in the Jakarta nexus repo during a vote and specifically not released to Maven central until all of the release criteria are met. This includes the specification committee voting, the PMC approval, and the EMO approval. There were no specifications that went to ballot with non-final api jars. They simply were not in Maven central.
On Thu, Nov 19, 2020 at 6:21 AM Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
Werner, yes, I mean the Jakarta EE platform. And no, it is definitively NOT done like that. There are some JARs currently NOT uploaded to Maven central while the ballot has successfully passed already (I checked that yesterday). And, some projects went into ballot with MRs/RCs definitively. If that wouldn't be the case, Steve never would have had a need to ask and I never have had to explain.
Von:jakartaee-platform-dev-bounces@xxxxxxxxxxx[mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] Im Auftrag von Werner Keil
With "Jakarta EE itself" I assume you mean the platforms like Full or Web Platform?
What you mentioned is done just like that at the moment. ;-)
All the individual specs were voted on before the Platform ballots took place.
Some were done relatively "Long before" others only a few weeks ago, but all happened before the platforms.
The standalone specs are also separate and only referenced from the platform specs in ways like
"The Jakarta Annotations specification can be found at https://jakarta.ee/specifications/annotations. "
I'd like to extend Ivar's answer by one point: Specs can publish many releases within the lifetime of one Jakarta EE release, hence their pushing is always unrelated of Jakarta EE and typically should be done *long before* Jakarta EE is iteself starting its ballot. In fact, what people "out there" expect is that the ballot for Jakarta EE is basing on already published specs, not basing on Milestones or Candidates. Looking on Jakarta EE from that point makes it clear that EE 8 and EE 9 enforced unneccessary and unwanted waiting, and we should never again without anything that successfully passed a ballot. These are not chapters of a book, these are standalone documents.
Von:jakartaee-platform-dev-bounces@xxxxxxxxxxx[mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] Im Auftrag von Steve Millidge (Payara)
Thanks I will get the checklist steps done now then
From:jakartaee-platform-dev-bounces@xxxxxxxxxxx<jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Ivar Grimstad
That is part of the competition steps for the specification project team after their ballot is passed. Should be done for each component specification as soon as possible after the ballot completes.
On Wed, Nov 18, 2020 at 6:54 PM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
I may have missed something but how is the release of apis jars to maven central being done for the release. Are we pushing jars that have passed all stages to central now or waiting for the Jakarta EE release date?
Jakarta EE Developer Advocate | Eclipse Foundation, Inc.
Eclipse Foundation- Community. Code. Collaboration.
Back to the top