Thanks Nicolas,
Actually when I read OFBIZ-6273 it seems Jacopo are on the same page than me:
The code that has been deprecated before December 2014 will be released
in the releases of the 14.12 branch: in this way users will be notified
about deprecated methods/code.
For this reason we can proceed and remove all the deprecated code from trunk,
deprecated before December 2014.
Anyway I'd like to have more opinions about *when to remove deprecated code
before writing definitive rules about it*.
It seems Jacopo, Scott and I are on the same page (please confirm guys).
And you Nicolas propose something which lets more time to users. This is maybe
not a bad idea, our users are our most important assets!
Jacques
Le 11/08/2017 à 20:52, Nicolas Malin a écrit :
Imagine we are the 30 december 2019 and we decide to create a new release.
We have on trunk :
* addCatalogMember deprecated since="next release"
* deleteRateAmount deprecated since="17.11"
* deleteWorkEffortAssignment depraceted since="18.12"
We prepare the release, we have on trunk :
* addCatalogMember deprecated since="19.12"
* deleteRateAmount deprecated since="17.11"
* deleteWorkEffortAssignment depraceted since="18.12"
We create the stable branche and after clean the trunk,
now on trunk we have :
* addCatalogMember deprecated since="19.12"
* deleteWorkEffortAssignment depraceted since="18.12"
I hope this example is less confused that the sentence :)
Nicolas
Le 11/08/2017 à 17:05, Jacques Le Roux a écrit :
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.stackexchange.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
