Re: Rule to deprecate a service
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: /<>/ 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 < jacques.le.r...@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
Re: Rule to deprecate a service
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: /<>/ 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 < jacques.le.r...@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
