People doing a lot of work on one project are probably capable of
working on many projects, and we should encourage them to apply
their skills more widely.
Markus KARG wrote on 12/22/19 2:35 AM:
I
understand your argument, but have a slightly different
view. For me the highest priority always have the people
actually doing the most work on each project, not
the ones that work on most projects.
-Markus
Von:
Bill Shannon [mailto:bill.shannon@xxxxxxxxxx]
Gesendet: Samstag, 21. Dezember 2019 21:29
An: Markus KARG; 'jaxrs developer discussions'
Betreff: Re: AW: [jaxrs-dev] Github Branches
In my opinion,
the simplest approach for most projects is to do the work for
the currently under development release on the master branch,
and reserve other branches for either work supporting previous
releases (maintenance) or work for future releases.
There is no one right way to do this, it's all a matter of
opinion, so you can do whatever makes sense and works for
you. As usual, my concern is that we should preserve as much
commonality as possible between projects in term of how
they're managed, to make it simpler for people to work on
multiple projects. What I described is what I believe to be
the most common approach.
Markus KARG wrote on 12/21/19 4:38 AM:
Yes
that is possible, it is simply no technical problem, just
time to invest to juggle with the commits.
What
do you try to reach? We certainly can do that, but what
benefit do you expect from it?
-Markus
Von:
Bill Shannon [mailto:bill.shannon@xxxxxxxxxx]
Gesendet: Samstag, 21. Dezember 2019 03:37
An: jaxrs developer discussions; Markus KARG
Betreff: Re: [jaxrs-dev] Github Branches
I'm not a
git expert, but...
Can you move everything on the master branch to a "3.1" (or
whatever) branch, then move everything on the EE4J_8 branch
to the master branch and use the master branch for the
"current release" (3.0) development while leaving the other
branch for the "future work" development?
Markus KARG wrote on 12/20/19 6:58 AM:
(1)
There is no need to actually keep a branch for
that purpose, as you can easily reconstruct it from the
corresponding tag (git checkout -b <NEW-BRANCH> 2.1.6),
as branches are for active development, while
tags are for archived streams. BTW, note that
"-1" means that we MUST NOT remove that branch even if all
other contributors would be +1 (e. g. due to that simple
git trick), so I'd like to ask if you really mean "-1"
or "0" (i. e. "I would like to keep it, but I do not
stand in the way of the majority").
Thanks.
-Markus
I would like to keep that branch
around in case we need to do another point release.
This should only mean very minor changes to the spec doc
or javadoc, etc, but if we do need to make a correction,
it will be a lot easier if the branch is still there.
Committers,
(1)
The EE4J PMC agreed that we may delete the
EE4J_8 branch, as Jakarta EE 8 was published
there is no more use of that branch. We need to
take care that everything in that branch is also
found in the master branch.
(2)
As the master branch contains new features, it
is targeting v3.1. As we need to provide a v3.0
for Jakarta EE 9, I propose we create a new
branch "3.0-SNAPSHOT" for that purpose (we
cannot call it "3.0" because it would interfer
with tag names) as a branch off master and
removing the new features manually.
If
nobody objects, I will perform these changes in
my X-mas holidays.
Vote,
please. :-)
-Markus
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jaxrs-dev
|
