ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepak Dixit <deepak.di...@hotwaxsystems.com>
Subject Re: Rule to deprecated a service
Date Wed, 16 Aug 2017 06:47:24 GMT
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 <nicolas.malin@nereide.fr>
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 <
>> jacques.le.roux@les7arts.com> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message