Our experience is that, between spec versions, updating the spec
with errata is independent of updating the API jar file. There is
no reason to update one when the other is updated.
Ivar Grimstad wrote on 6/18/19 11:39
PM:
We keep the asciidoc-files for the specification in
the same repo as the API jars in the MVC specification.
The reason for doing so is that we release them
simultaneously with the same version number. The TCK has
potentially a different release cycle, so it makes sense to
separate out in a separate repository.
At least, that is how we are thinking.
I think we should write up some guidelines, as you suggest.
Rules (heaven forbid :)) is going a little too far...
The guidelines should be stated by the specification
committee since it affects the Jakarta projects, but the EE4J
PMC will be happy to guide and advice the projects accordingly
and publish the guidelines on the EE4J website.
Ivar
Why do you think they should all be in
the same repo?
Clearly the spec, API, and TCK will all be part of the same
project, which controls who has permission to do
what. Why would two of them be in one repo and one of them
in another repo?
Scott
Stark wrote on 6/18/19 9:20 PM:
I do believe the spec and api
should be in the same repo. The TCKs should be in a
separate repo.
Anyone else have an
opinion?
Do we want to establish any conventions or
guidelines or (heaven forbid) rules?
I'm not sure putting the spec document in the
same repo as the API classes is the best choice,
but really I'm much more concerned about having
some consistency in where to go for the web site
with information about each spec.
Wayne
Beaton wrote on 6/18/19 7:32 PM:
I have no strong opinion.
The PMC has made a recommendation that
specification documents be represented in
existing API repositories. At least a few
project teams have expressed a desire to
do this. I'm sure that some project teams
will make other decisions. So, there will
likely be few "wombat-spec" repositories.
As part of the restructuring review, I
am assuming that projects will use
existing "API" repositories. If a project
team wants a separate "spec" repository,
they can ask for one.
Wayne
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.
_______________________________________________
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
_______________________________________________
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
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
_______________________________________________
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
|
