Rule to deprecated a service

[Jacques Le Roux]

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
>>>>
>>>
>>>
>>
>>
>
>

[Michael Brohl-3]

Since we do a major release only once a year, maybe more, I think it is
enough time for users to follow-up the changes if we proceed as you
described.

There might be exceptions, e.g. if we make changes in an API which is
widely used.

One thing I would like to add: if we deprecate code, we should also
change the use of the deprecated code to an alternative (if there is
one) *in the same commit*. This way all users have enough time to get
used to the alternative API/code and can also follow the changes as a
migration example for their own code.

We should also have a Jira for every deprecation and the corresponding
changes.

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 12.08.17 um 11:03 schrieb Jacques Le Roux:

> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

[Deepak Dixit-3]

Thank Jacques,

>>>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.

I am also on same page . We tag code deprecated as a part of release and
these code will be removed from next release.
Lets say we set Release 17.XX as deprecated for an service, this service
will be part of Release17.XX and will be removed in next Release 18.XX





Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Sat, Aug 12, 2017 at 2:33 PM, Jacques Le Roux <
[hidden email]> wrote:

> 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.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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>

[Jacques Le Roux]

Thanks Deepak,

You said

 > We tag code deprecated as a part of release and these code will be removed from next release.

I agree this is the process once we have removed all deprecated stuff.

But there still are older stuff pending. So we need 1st to remove all what is deprecated to simply rely on it.

For instance look at the ByteWrapper class.

Fortunately, at least in Java code, there are not much waiting.

But I wonder about all the rest (widgets, etc.), where AFAIK we have not yet a simple mechanism to track things, apart, thanks Nicolas, services.

Jacques


Le 14/08/2017 à 07:48, Deepak Dixit a écrit :

> Thank Jacques,
>
>>>> 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.
>
> I am also on same page . We tag code deprecated as a part of release and
> these code will be removed from next release.
> Lets say we set Release 17.XX as deprecated for an service, this service
> will be part of Release17.XX and will be removed in next Release 18.XX
>
>
>
>
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
> www.hotwax.co
>
> On Sat, Aug 12, 2017 at 2:33 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> 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.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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>

[Nicolas Malin-2]

Le 14/08/2017 à 07:48, Deepak Dixit a écrit :

> Thank Jacques,
>
>>>> 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.
>
> I am also on same page . We tag code deprecated as a part of release and
> these code will be removed from next release.
> Lets say we set Release 17.XX as deprecated for an service, this service
> will be part of Release17.XX and will be removed in next Release 18.XX

Sometime it would be good to stop my work when I'm tired :) I restart my
example because it's wrong with my brain :
Imagine we are the 30 december 2019 and we decide to create a new release.
We have on trunk :
  * addCatalogMember deprecated since="next release"
  * deleteWorkEffortAssignment depraceted since="18.12"

We prepare the release, we have on trunk :
  * addCatalogMember deprecated since="19.12"
  * 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"

It's in coherence with your remark Deepak ?

Nicolas

> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
> www.hotwax.co
>
> On Sat, Aug 12, 2017 at 2:33 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> 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.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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>

[Jacques Le Roux]

Thanks Nicolas :)

It's with mine at least and I guess Jacopo's, Scott's and Deepak's, right guys?

W/o answers I will soon consider the status quo a consensus ans will write the rules in wiki

Jacques


Le 14/08/2017 à 14:51, Nicolas Malin a écrit :

> Le 14/08/2017 à 07:48, Deepak Dixit a écrit :
>> Thank Jacques,
>>
>>>>> 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.
>>
>> I am also on same page . We tag code deprecated as a part of release and
>> these code will be removed from next release.
>> Lets say we set Release 17.XX as deprecated for an service, this service
>> will be part of Release17.XX and will be removed in next Release 18.XX
> Sometime it would be good to stop my work when I'm tired :) I restart my example because it's wrong with my brain :
> Imagine we are the 30 december 2019 and we decide to create a new release.
> We have on trunk :
>  * addCatalogMember deprecated since="next release"
>  * deleteWorkEffortAssignment depraceted since="18.12"
>
> We prepare the release, we have on trunk :
>  * addCatalogMember deprecated since="19.12"
>  * 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"
>
> It's in coherence with your remark Deepak ?
>
> Nicolas
>> Thanks & Regards
>> --
>> Deepak Dixit
>> www.hotwaxsystems.com
>> www.hotwax.co
>>
>> On Sat, Aug 12, 2017 at 2:33 PM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>>> 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.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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>
>

[Deepak Dixit-3]

Yes Nicolas.

Nicely explained.

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Mon, Aug 14, 2017 at 6:21 PM, Nicolas Malin <[hidden email]>
wrote:

> Le 14/08/2017 à 07:48, Deepak Dixit a écrit :
>
>> Thank Jacques,
>>
>> 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.
>>
>> I am also on same page . We tag code deprecated as a part of release and
>> these code will be removed from next release.
>> Lets say we set Release 17.XX as deprecated for an service, this service
>> will be part of Release17.XX and will be removed in next Release 18.XX
>>
> Sometime it would be good to stop my work when I'm tired :) I restart my
> example because it's wrong with my brain :
> Imagine we are the 30 december 2019 and we decide to create a new release.
> We have on trunk :
>  * addCatalogMember deprecated since="next release"
>  * deleteWorkEffortAssignment depraceted since="18.12"
>
> We prepare the release, we have on trunk :
>  * addCatalogMember deprecated since="19.12"
>  * 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"
>
> It's in coherence with your remark Deepak ?
>
> Nicolas
>
> Thanks & Regards
>> --
>> Deepak Dixit
>> www.hotwaxsystems.com
>> www.hotwax.co
>>
>> On Sat, Aug 12, 2017 at 2:33 PM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>> 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.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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>

[Jacques Le Roux]

Done at https://s.apache.org/12Uq

Jacques


Le 14/08/2017 à 18:05, Jacques Le Roux a écrit :

> Thanks Nicolas :)
>
> It's with mine at least and I guess Jacopo's, Scott's and Deepak's, right guys?
>
> W/o answers I will soon consider the status quo a consensus ans will write the rules in wiki
>
> Jacques
>
>
> Le 14/08/2017 à 14:51, Nicolas Malin a écrit :
>> Le 14/08/2017 à 07:48, Deepak Dixit a écrit :
>>> Thank Jacques,
>>>
>>>>>> 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.
>>>
>>> I am also on same page . We tag code deprecated as a part of release and
>>> these code will be removed from next release.
>>> Lets say we set Release 17.XX as deprecated for an service, this service
>>> will be part of Release17.XX and will be removed in next Release 18.XX
>> Sometime it would be good to stop my work when I'm tired :) I restart my example because it's wrong with my brain :
>> Imagine we are the 30 december 2019 and we decide to create a new release.
>> We have on trunk :
>>  * addCatalogMember deprecated since="next release"
>>  * deleteWorkEffortAssignment depraceted since="18.12"
>>
>> We prepare the release, we have on trunk :
>>  * addCatalogMember deprecated since="19.12"
>>  * 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"
>>
>> It's in coherence with your remark Deepak ?
>>
>> Nicolas
>>> Thanks & Regards
>>> --
>>> Deepak Dixit
>>> www.hotwaxsystems.com
>>> www.hotwax.co
>>>
>>> On Sat, Aug 12, 2017 at 2:33 PM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>> 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.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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>
>>
>
>

[Nicolas Malin-2]

Thanks for the work Jacques.

Nicolas


Le 29/09/2017 à 09:49, Jacques Le Roux a écrit :

> Done at https://s.apache.org/12Uq
>
> Jacques
>
>
> Le 14/08/2017 à 18:05, Jacques Le Roux a écrit :
>> Thanks Nicolas :)
>>
>> It's with mine at least and I guess Jacopo's, Scott's and Deepak's,
>> right guys?
>>
>> W/o answers I will soon consider the status quo a consensus ans will
>> write the rules in wiki
>>
>> Jacques
>>
>>
>> Le 14/08/2017 à 14:51, Nicolas Malin a écrit :
>>> Le 14/08/2017 à 07:48, Deepak Dixit a écrit :
>>>> Thank Jacques,
>>>>
>>>>>>> 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.
>>>>
>>>> I am also on same page . We tag code deprecated as a part of
>>>> release and
>>>> these code will be removed from next release.
>>>> Lets say we set Release 17.XX as deprecated for an service, this
>>>> service
>>>> will be part of Release17.XX and will be removed in next Release 18.XX
>>> Sometime it would be good to stop my work when I'm tired :) I
>>> restart my example because it's wrong with my brain :
>>> Imagine we are the 30 december 2019 and we decide to create a new
>>> release.
>>> We have on trunk :
>>>  * addCatalogMember deprecated since="next release"
>>>  * deleteWorkEffortAssignment depraceted since="18.12"
>>>
>>> We prepare the release, we have on trunk :
>>>  * addCatalogMember deprecated since="19.12"
>>>  * 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"
>>>
>>> It's in coherence with your remark Deepak ?
>>>
>>> Nicolas
>>>> Thanks & Regards
>>>> --
>>>> Deepak Dixit
>>>> www.hotwaxsystems.com
>>>> www.hotwax.co
>>>>
>>>> On Sat, Aug 12, 2017 at 2:33 PM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>>> 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.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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>
>>>
>>
>>
>
>

[Jacques Le Roux]

Hi,

Sorry to resurrect this thread.

In relation with OFBIZ-11435, I have tried to clarify the information about deprecated services at https://s.apache.org/7pra2.

I went back to the discussion in this thread to be sure to reflect the community decision.

The initial reason which makes me change is that in the wiki we used "next release" when actually people are using "Upcoming branch" in code, which is
consistent with Jira.

I also wanted to clarify when and who should remove deprecated services. As described in the wiki, we implicitly decided it's a RM's (Release Manager)
task. Because, so far, the RM creates the new branches.

As I did not want to add a new wiki page only for that action, I updated the
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz page, and added:

    /<<Check if there are deprecated services to remove. That's easily done by looking for "has been deprecated and replaced by" in console.log.>>/

I hope I wrote things as simple as possible (here and in the wiki), please check!

Jacques


Le 29/09/2017 à 19:47, Nicolas Malin a écrit :

> Thanks for the work Jacques.
>
> Nicolas
>
>
> Le 29/09/2017 à 09:49, Jacques Le Roux a écrit :
>> Done at https://s.apache.org/12Uq
>>
>> Jacques
>>
>>
>> Le 14/08/2017 à 18:05, Jacques Le Roux a écrit :
>>> Thanks Nicolas :)
>>>
>>> It's with mine at least and I guess Jacopo's, Scott's and Deepak's, right guys?
>>>
>>> W/o answers I will soon consider the status quo a consensus ans will write the rules in wiki
>>>
>>> Jacques
>>>
>>>
>>> Le 14/08/2017 à 14:51, Nicolas Malin a écrit :
>>>> Le 14/08/2017 à 07:48, Deepak Dixit a écrit :
>>>>> Thank Jacques,
>>>>>
>>>>>>>> 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.
>>>>>
>>>>> I am also on same page . We tag code deprecated as a part of release and
>>>>> these code will be removed from next release.
>>>>> Lets say we set Release 17.XX as deprecated for an service, this service
>>>>> will be part of Release17.XX and will be removed in next Release 18.XX
>>>> Sometime it would be good to stop my work when I'm tired :) I restart my example because it's wrong with my brain :
>>>> Imagine we are the 30 december 2019 and we decide to create a new release.
>>>> We have on trunk :
>>>>  * addCatalogMember deprecated since="next release"
>>>>  * deleteWorkEffortAssignment depraceted since="18.12"
>>>>
>>>> We prepare the release, we have on trunk :
>>>>  * addCatalogMember deprecated since="19.12"
>>>>  * 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"
>>>>
>>>> It's in coherence with your remark Deepak ?
>>>>
>>>> Nicolas
>>>>> Thanks & Regards
>>>>> --
>>>>> Deepak Dixit
>>>>> www.hotwaxsystems.com
>>>>> www.hotwax.co
>>>>>
>>>>> On Sat, Aug 12, 2017 at 2:33 PM, Jacques Le Roux <
>>>>> [hidden email]> wrote:
>>>>>
>>>>>> 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.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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

[Jacques Le Roux]

Forgot to mention that we have so far never removed a deprecated services. Not surprising, the feature is rather new.

Le 11/05/2020 à 21:22, Jacques Le Roux a écrit :

> Hi,
>
> Sorry to resurrect this thread.
>
> In relation with OFBIZ-11435, I have tried to clarify the information about deprecated services at https://s.apache.org/7pra2.
>
> I went back to the discussion in this thread to be sure to reflect the community decision.
>
> The initial reason which makes me change is that in the wiki we used "next release" when actually people are using "Upcoming branch" in code, which
> is consistent with Jira.
>
> I also wanted to clarify when and who should remove deprecated services. As described in the wiki, we implicitly decided it's a RM's (Release
> Manager) task. Because, so far, the RM creates the new branches.
>
> As I did not want to add a new wiki page only for that action, I updated the
> https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz page, and added:
>
>    /<<Check if there are deprecated services to remove. That's easily done by looking for "has been deprecated and replaced by" in console.log.>>/
>
> I hope I wrote things as simple as possible (here and in the wiki), please check!
>
> Jacques
>
>
> Le 29/09/2017 à 19:47, Nicolas Malin a écrit :
>> Thanks for the work Jacques.
>>
>> Nicolas
>>
>>
>> Le 29/09/2017 à 09:49, Jacques Le Roux a écrit :
>>> Done at https://s.apache.org/12Uq
>>>
>>> Jacques
>>>
>>>
>>> Le 14/08/2017 à 18:05, Jacques Le Roux a écrit :
>>>> Thanks Nicolas :)
>>>>
>>>> It's with mine at least and I guess Jacopo's, Scott's and Deepak's, right guys?
>>>>
>>>> W/o answers I will soon consider the status quo a consensus ans will write the rules in wiki
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 14/08/2017 à 14:51, Nicolas Malin a écrit :
>>>>> Le 14/08/2017 à 07:48, Deepak Dixit a écrit :
>>>>>> Thank Jacques,
>>>>>>
>>>>>>>>> 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.
>>>>>>
>>>>>> I am also on same page . We tag code deprecated as a part of release and
>>>>>> these code will be removed from next release.
>>>>>> Lets say we set Release 17.XX as deprecated for an service, this service
>>>>>> will be part of Release17.XX and will be removed in next Release 18.XX
>>>>> Sometime it would be good to stop my work when I'm tired :) I restart my example because it's wrong with my brain :
>>>>> Imagine we are the 30 december 2019 and we decide to create a new release.
>>>>> We have on trunk :
>>>>>  * addCatalogMember deprecated since="next release"
>>>>>  * deleteWorkEffortAssignment depraceted since="18.12"
>>>>>
>>>>> We prepare the release, we have on trunk :
>>>>>  * addCatalogMember deprecated since="19.12"
>>>>>  * 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"
>>>>>
>>>>> It's in coherence with your remark Deepak ?
>>>>>
>>>>> Nicolas
>>>>>> Thanks & Regards
>>>>>> --
>>>>>> Deepak Dixit
>>>>>> www.hotwaxsystems.com
>>>>>> www.hotwax.co
>>>>>>
>>>>>> On Sat, Aug 12, 2017 at 2:33 PM, Jacques Le Roux <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>>> 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.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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>