[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-spec.committee] Version control on the EE4J Release Records
|
Hmmm... I don't
seem to have those options. I also don't see the "Devel"
option across the top. Are these maybe "special powers"
that mere mortals do not have?
---------------------------------------------------
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:
Wayne
Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>To:
Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>Date:
02/05/2020
15:22Subject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] Version control on the EE4J Release
RecordsSent
by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
When you edit a record in the PMI, you
have an option to create a revision. I've attached a screenshot.
It's theoretically possible to force
every "save" to create a revision automatically, but that doesn't
help you identify (other than heuristically by date, of course) which revision
is the "original".This also suffers from the limitation
that only committers can actually change it, only one of them can edit
it at any time (optimistic locking), and collaboration would need to be
in an entirely separate channel (there's no communication channel associated
with revisions).Putting the plan into a GitHub repository
has the benefit of keeping the plan close to the content (which I think
is useful) and makes it possible for non-committer collaborators to more
directly participate in the planning process.HTH,WayneOn Wed, Feb 5, 2020 at 3:51 PM Kevin
Sutter <sutter@xxxxxxxxxx>
wrote:At today's Spec
call, Wayne mentioned that the Release Records could have version control
enabled. I'd like to explore that possibility a bit... Since
none of our projects have this enabled, how would this work? Are
there any examples of projects that use the version control on their release
records that we could view? Or, maybe a mock up on one of our projects
to experiment with?
At a minimum, it might be nice to lock down a release record when we have
completed a successful ballot. We record the ballot results in the
Specifications repo. But, where do we record the actual release plan
that we approved? We discussed the storing of release plans in github
like the Platform and EJB are doing. But, locking down the content
of the Activation release record after the ballot passes might be nice.
As David pointed out -- for historical reference purposes.
So, I'm wondering what type of mechanisms we might already have in place
versus what might need to be developed. I'm just looking for something
simple. 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 change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee-- 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