Hi Nicolas,
I'm unsure about your point
"remove all element contains with a since not on the last stable
branch
on trunk"
I guess you mean
"to remove on trunk all elements which contains a
'since=releaseBranchNumber' with releaseBranchNumber being
different from
the last stable branch just created"
For instance in your example we would remove all elements
deprecated but
not those marked with deprecated with 'since=17.11'
Right?
Please confirm and others please raise a hand if you disagree.
IMO we could remove all deprecated code from trunk at this
moment. I
mean, we would not even keep services with 'since=17.11'
So to be totally clear, my take is to remove all deprecated code
(not
only services) when we release a branch. In other words just
after the 1st
release of a branch the trunk should no longer contain any
deprecated code.
Is that too much and early ?
Another possibility would be to remove all the deprecated code
from the
trunk when releasing the last release of the last branch (ie
when a branch
get to its End Of Life/Support)
Would be the rule Nicolas proposes better ? ie, if I have well
understood, we keep in trunk the deprecated code deprecated
between the
creation of the "old" (previous stable) and the (new) stable branch
I guess whether rule we pick we all agree that it must apply to
all code
not only services, or Java code, etc.
Some suggest to keep the deprecated code during 2-3 versions
(OFBiz code
can be considered an API): https://softwareengineering.st
ackexchange.com/questions/67837/when-to-deprecate-and-when-
to-delete-in-java
So what are your opinions :) ?
Jacques
Le 11/08/2017 à 12:08, Nicolas Malin a écrit :
Hello,
I imagine the following process :
* deprecated on trunk an element and indicate
since="$NextReleaseBranch" (or somethink like that)
* When before create the new release branch like 17.11 :
** run a replaceAll $NextReleaseBranch by 17.11
** update the trunk
* Create the new stable branch
* remove all element contains with a since not on the last stable
branch on trunk
* update trunk
With this we have a new stable branch with the deprecated from the
previous stable branch (keep stability much as possible), and a
trunk
cleaned of old deprecated who may introduce a potential
instability but we
have the time to correct it.
Nicolas
Le 10/08/2017 à 13:46, Jacques Le Roux a écrit :
Le 10/08/2017 à 13:25, Scott Gray a écrit :
I think we've had these discussions before Jacques, I'd
search the
mailing
lists and then perhaps only continue the conversation if you
have
concerns
about what was agreed previously.
I'm pretty sure the policy was "remove after the next release is
out", and
actually released, not just when a branch is cut.
Oops, that's what I meant too with "deprecate code when we
create the
first release of the last freezed branch".
I tried to be more precise there than in my previous sentence
"remove
all deprecated code in trunk when for instance creating a new
release."
But I did not notice I misused "deprecate code" for "remove
deprecated
code".
I think we are on the same page and don't want to wait loo long
keeping deprecated code, first occasion is best ;)
Jacques