Apparently I'm not able to convince you of the benefit of common
practices since every time I suggest that using common practices
would be better you come back with a reason for why it's better to
do things in your own unique way.
And yes, the highly skilled people who are capable of contributing
to multiple projects will also be capable of adapting to the unique
requirements of each project. That doesn't mean it's better for
each project to have unique ways of doing common operations, it just
means it's not fatal.
Markus KARG wrote on 12/22/19 1:00 PM:
If you actually find those people I am
happy to explain them our branch names once they really
produced valueable Content for JAX-RS and could really not
contribute them without!
-Markus
P.S.: I’m doing open source since 20 years
in lots of projects. No need to teach me the benefit of common
practices. I was able to easily contribute to all of them, and
to adopt all their particular styles and ways.
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
|
