[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cu-dev] Thoughts on how to manage PRs for new api features
|
I'd say let's try
the simpler approach first (create pull against master, discuss & vote,
iterating if needed, and merge after agreed upon) and if that is found
to become cumbersome at any point, then consider the other approach.
From:
"Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>To:
cu
developer discussions <cu-dev@xxxxxxxxxxx>Date:
03/17/2021
10:45 AMSubject:
[EXTERNAL]
[cu-dev] Thoughts on how to manage PRs for new api featuresSent
by: "cu-dev"
<cu-dev-bounces@xxxxxxxxxxx>
How do people feel we should
manage feature development in the repo for Jakarta EE 10? A couple of options
from me. People make PRs to master for api proposals? When agreed and voted
on the PR we merge the PR? This could become cumbersome with How
do people feel we should manage feature development in the repo for Jakarta
EE 10?
A
couple of options from me.
People
make PRs to master for api proposals? When agreed and voted on the PR we
merge the PR?
This
could become cumbersome with a lot of comments on a single PR.
We
create a feature branch, one per issue, and allow PRs and merge PRs to
the feature branch. Then when we are happy with a feature create a final
PR to master where people can vote?
Any
other options?
Thanks
Steve_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev