Hi James,
I'm not sure of the purpose of doing all of that? start.properties is a file to feed into Config.java which in turn configures the startup settings of OFBiz. The version has nothing with the startup code so it seems like an improper place to put the property and maybe it might confuse users. Also, why go through all this logic? why not simply create a VERSION file and place the version in it? Much simpler and easier if all you need is a version reference. Unless you want to introduce some logic? On Tue, Nov 28, 2017 at 6:04 PM, James Yong <[hidden email]> wrote: > Hi all, > > If there is no further discusson, I will create a JIRA issue later to > 1) add an ofbiz.version key in start.properties file; and > 2) have the ofbiz.version key value included in the startup message. > > Regards, > James Yong > > On 2017-11-28 01:35, Jacques Le Roux <[hidden email]> wrote: >> OK then if we have both, why not? >> >> Jacques >> >> >> Le 27/11/2017 à 17:15, James Yong a écrit : >> > Hi Jacques, >> > >> > The developer can refer to the proposed ofbiz.version property if needed. >> > >> > Regards, >> > James Yong >> > >> > On 2017-11-28 00:03, Jacques Le Roux <[hidden email]> wrote: >> >> Hi James, >> >> >> >> That's good when you start but could be hard to find after many days running in production for instance >> >> >> >> Jacques >> >> >> >> >> >> Le 27/11/2017 à 15:43, James Yong a écrit : >> >>> Hi all, >> >>> >> >>> How about hardcoding the released version in start.properties? >> >>> E.g. >> >>> ofbiz.version=v16.11.03 >> >>> >> >>> During startup, we can print out the version as part of the startup message like: >> >>> ____ __________ _ >> >>> / __ \/ ____/ __ )(_)___ >> >>> / / / / /_ / __ / /_ / >> >>> / /_/ / __/ / /_/ / / / /_ >> >>> \____/_/ /_____/_/ /___/ v16.11.03 is started and ready. >> >>> >> >>> Just update the released version in the properties before a release. >> >>> >> >>> Regards, >> >>> James Yong >> >>> >> >>> >> >>> On 2017-11-27 22:08, Akash Jain <[hidden email]> wrote: >> >>>> +1, version information should available somewhere, it will be helpful. >> >>>> >> >>>> Thanks and Regards >> >>>> -- >> >>>> Akash Jain >> >>>> >> >>>> On Mon, Nov 27, 2017 at 6:07 PM, Sharan Foga <[hidden email]> wrote: >> >>>> >> >>>>> Hi >> >>>>> >> >>>>> Having the version info available somehow could be useful. Whenever a user >> >>>>> reports a problem on our user lists, one of the first questions we ask them >> >>>>> is "What version are you using?" >> >>>>> >> >>>>> Perhaps asking the question about version information, on the user list >> >>>>> might help. >> >>>>> >> >>>>> Thanks >> >>>>> Sharan >> >>>>> >> >>>>> On 2017-11-27 08:49, Pierre Smits <[hidden email]> wrote: >> >>>>>> Hi Devanshu Vyas, >> >>>>>> >> >>>>>> Please see inline. >> >>>>>> >> >>>>>> Best regards, >> >>>>>> >> >>>>>> Pierre Smits >> >>>>>> >> >>>>>> ORRTIZ.COM <http://www.orrtiz.com> >> >>>>>> OFBiz based solutions & services >> >>>>>> >> >>>>>> OEM - The OFBiz Extensions Marketplace1 >> >>>>>> http://oem.ofbizci.net/oci-2/ >> >>>>>> 1 not affiliated to (and not endorsed by) the OFBiz project >> >>>>>> >> >>>>>> On Mon, Nov 27, 2017 at 7:33 AM, Devanshu Vyas < >> >>>>> [hidden email]> >> >>>>>> wrote: >> >>>>>> >> >>>>>>> Thank you all for your thoughts on this. >> >>>>>>> >> >>>>>>> I really like the idea shared by Taher to create a version file using >> >>>>>>> target and after second thought I agree that it can be a tiresome task >> >>>>> to >> >>>>>>> update version info manually with each release. >> >>>>>>> But before we conclude this discussion, I would like to share another >> >>>>>>> thought with you. I think we can add OFBiz version info in the >> >>>>> licensing >> >>>>>>> information we add to our files. >> >>>>>>> I know it will be a manual task, but can be easily done with a simple >> >>>>> Find >> >>>>>>> & Replace. >> >>>>>>> >> >>>>>>> I am happy to work on the whichever implementation we decide >> >>>>> here(hoping I >> >>>>>>> am not stepping on anyone's toes). >> >>>>>>> >> >>>>>> Don't worry. I bet you aren't. ;) >> >>>>>> >> >>>>>> >> >>>>>>> And my reason to raise the concern was that it is very difficult to >> >>>>>>> identify which version of code a user is using(a real-time scenario >> >>>>> where I >> >>>>>>> was exposed to OFBiz code and I couldn't perform anything on it. So >> >>>>> just by >> >>>>>>> looking at it, I was unable to determine what version it was) >> >>>>>>> >> >>>>>>> >> >>>>>> So you experienced a user being exposed to a OOTB OFBiz deployment, >> >>>>>> deployed by your employer HotWax? Or was the user exposed to a deployment >> >>>>>> that was also modified? In either case this is an issue related to the >> >>>>>> Release Management process applied. And not necessarily an OFBIZ problem. >> >>>>>> >> >>>>>> >> >>>>>>> Waiting for your replies!! >> >>>>>>> >> >>>>>>> >> >>>>>>> Thanks & Regards, >> >>>>>>> Devanshu Vyas. >> >>>>>>> >> >> >> >> |
Hi Taher,
The reason of putting released version (e.g. 16.11.03) in start.properties file is because the start program is already reading that file and that info will be included in the startup message. Printing released version to the console is in line with what other applications, like Tomcat, have been doing. I haven't check how the start program will read the VERSION file but I have no issue with this approach and we can further discuss how it can be done. Regards, James Yong On 2017-11-29 02:51, Taher Alkhateeb <[hidden email]> wrote: > Hi James, > > I'm not sure of the purpose of doing all of that? start.properties is > a file to feed into Config.java which in turn configures the startup > settings of OFBiz. The version has nothing with the startup code so it > seems like an improper place to put the property and maybe it might > confuse users. > > Also, why go through all this logic? why not simply create a VERSION > file and place the version in it? Much simpler and easier if all you > need is a version reference. Unless you want to introduce some logic? > > On Tue, Nov 28, 2017 at 6:04 PM, James Yong <[hidden email]> wrote: > > Hi all, > > > > If there is no further discusson, I will create a JIRA issue later to > > 1) add an ofbiz.version key in start.properties file; and > > 2) have the ofbiz.version key value included in the startup message. > > > > Regards, > > James Yong > > > > On 2017-11-28 01:35, Jacques Le Roux <[hidden email]> wrote: > >> OK then if we have both, why not? > >> > >> Jacques > >> > >> > >> Le 27/11/2017 à 17:15, James Yong a écrit : > >> > Hi Jacques, > >> > > >> > The developer can refer to the proposed ofbiz.version property if needed. > >> > > >> > Regards, > >> > James Yong > >> > > >> > On 2017-11-28 00:03, Jacques Le Roux <[hidden email]> wrote: > >> >> Hi James, > >> >> > >> >> That's good when you start but could be hard to find after many days running in production for instance > >> >> > >> >> Jacques > >> >> > >> >> > >> >> Le 27/11/2017 à 15:43, James Yong a écrità : > >> >>> Hi all, > >> >>> > >> >>> How about hardcoding the released version in start.properties? > >> >>> E.g. > >> >>> ofbiz.version=v16.11.03 > >> >>> > >> >>> During startup, we can print out the version as part of the startup message like: > >> >>> ____ __________ _ > >> >>> / __ \/ ____/ __ )(_)___ > >> >>> / / / / /_ / __ / /_ / > >> >>> / /_/ / __/ / /_/ / / / /_ > >> >>> \____/_/ /_____/_/ /___/ v16.11.03 is started and ready. > >> >>> > >> >>> Just update the released version in the properties before a release. > >> >>> > >> >>> Regards, > >> >>> James Yong > >> >>> > >> >>> > >> >>> On 2017-11-27 22:08, Akash Jain <[hidden email]> wrote: > >> >>>> +1, version information should available somewhere, it will be helpful. > >> >>>> > >> >>>> Thanks and Regards > >> >>>> -- > >> >>>> Akash Jain > >> >>>> > >> >>>> On Mon, Nov 27, 2017 at 6:07 PM, Sharan Foga <[hidden email]> wrote: > >> >>>> > >> >>>>> Hi > >> >>>>> > >> >>>>> Having the version info available somehow could be useful. Whenever a user > >> >>>>> reports a problem on our user lists, one of the first questions we ask them > >> >>>>> is "What version are you using?" > >> >>>>> > >> >>>>> Perhaps asking the question about version information, on the user list > >> >>>>> might help. > >> >>>>> > >> >>>>> Thanks > >> >>>>> Sharan > >> >>>>> > >> >>>>> On 2017-11-27 08:49, Pierre Smits <[hidden email]> wrote: > >> >>>>>> Hi Devanshu Vyas, > >> >>>>>> > >> >>>>>> Please see inline. > >> >>>>>> > >> >>>>>> Best regards, > >> >>>>>> > >> >>>>>> Pierre Smits > >> >>>>>> > >> >>>>>> ORRTIZ.COM <http://www.orrtiz.com> > >> >>>>>> OFBiz based solutions & services > >> >>>>>> > >> >>>>>> OEM - The OFBiz Extensions Marketplace1 > >> >>>>>> http://oem.ofbizci.net/oci-2/ > >> >>>>>> 1 not affiliated to (and not endorsed by) the OFBiz project > >> >>>>>> > >> >>>>>> On Mon, Nov 27, 2017 at 7:33 AM, Devanshu Vyas < > >> >>>>> [hidden email]> > >> >>>>>> wrote: > >> >>>>>> > >> >>>>>>> Thank you all for your thoughts on this. > >> >>>>>>> > >> >>>>>>> I really like the idea shared by Taher to create a version file using > >> >>>>>>> target and after second thought I agree that it can be a tiresome task > >> >>>>> to > >> >>>>>>> update version info manually with each release. > >> >>>>>>> But before we conclude this discussion, I would like to share another > >> >>>>>>> thought with you. I think we can add OFBiz version info in the > >> >>>>> licensing > >> >>>>>>> information we add to our files. > >> >>>>>>> I know it will be a manual task, but can be easily done with a simple > >> >>>>> Find > >> >>>>>>> & Replace. > >> >>>>>>> > >> >>>>>>> I am happy to work on the whichever implementation we decide > >> >>>>> here(hoping I > >> >>>>>>> am not stepping on anyone's toes). > >> >>>>>>> > >> >>>>>> Don't worry. I bet you aren't. ;) > >> >>>>>> > >> >>>>>> > >> >>>>>>> And my reason to raise the concern was that it is very difficult to > >> >>>>>>> identify which version of code a user is using(a real-time scenario > >> >>>>> where I > >> >>>>>>> was exposed to OFBiz code and I couldn't perform anything on it. So > >> >>>>> just by > >> >>>>>>> looking at it, I was unable to determine what version it was) > >> >>>>>>> > >> >>>>>>> > >> >>>>>> So you experienced a user being exposed to a OOTB OFBiz deployment, > >> >>>>>> deployed by your employer HotWax? Or was the user exposed to a deployment > >> >>>>>> that was also modified? In either case this is an issue related to the > >> >>>>>> Release Management process applied. And not necessarily an OFBIZ problem. > >> >>>>>> > >> >>>>>> > >> >>>>>>> Waiting for your replies!! > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> Thanks & Regards, > >> >>>>>>> Devanshu Vyas. > >> >>>>>>> > >> >> > >> > >> > |
Hi James,
The purpose of Config.java is to configure critical server settings at startup such as log location, admin settings, etc. These settings could be also used in test.properties and load-data.properties and all such properties get a default value if not set. OFBiz version by definition is not a startup parameter. It is not something you need to set so that the system works correctly. It's only a piece of information. That is why I suggested that it might not be a good fit for start.properties and Config.java. It's also hard for users to find the version if it is hidden somewhere like that. And given the nature of verbose logging in OFBiz I suspect that it might not be very useful to spit out OFBiz version in the logs because it will be lost in the mix. So if I may suggest maybe there are a few alternatives that could work like: - adding it to another properties file like general.properties (although still a bit hidden yet more related than start.properties) - adding it to the UiLabelMap and putting it in the footer of the system - putting it in a VERSION file or README.md as originally suggested I'm sure you can also come up with good ideas to that end, I'm just thinking quickly of alternatives that might fit. On Nov 29, 2017 2:30 AM, "James Yong" <[hidden email]> wrote: Hi Taher, The reason of putting released version (e.g. 16.11.03) in start.properties file is because the start program is already reading that file and that info will be included in the startup message. Printing released version to the console is in line with what other applications, like Tomcat, have been doing. I haven't check how the start program will read the VERSION file but I have no issue with this approach and we can further discuss how it can be done. Regards, James Yong On 2017-11-29 02:51, Taher Alkhateeb <[hidden email]> wrote: > Hi James, > > I'm not sure of the purpose of doing all of that? start.properties is > a file to feed into Config.java which in turn configures the startup > settings of OFBiz. The version has nothing with the startup code so it > seems like an improper place to put the property and maybe it might > confuse users. > > Also, why go through all this logic? why not simply create a VERSION > file and place the version in it? Much simpler and easier if all you > need is a version reference. Unless you want to introduce some logic? > > On Tue, Nov 28, 2017 at 6:04 PM, James Yong <[hidden email]> wrote: > > Hi all, > > > > If there is no further discusson, I will create a JIRA issue later to > > 1) add an ofbiz.version key in start.properties file; and > > 2) have the ofbiz.version key value included in the startup message. > > > > Regards, > > James Yong > > > > On 2017-11-28 01:35, Jacques Le Roux <[hidden email]> > >> OK then if we have both, why not? > >> > >> Jacques > >> > >> > >> Le 27/11/2017 à 17:15, James Yong a écrit : > >> > Hi Jacques, > >> > > >> > The developer can refer to the proposed ofbiz.version property if needed. > >> > > >> > Regards, > >> > James Yong > >> > > >> > On 2017-11-28 00:03, Jacques Le Roux <[hidden email]> wrote: > >> >> Hi James, > >> >> > >> >> That's good when you start but could be hard to find after many days running in production for instance > >> >> > >> >> Jacques > >> >> > >> >> > >> >> Le 27/11/2017 à 15:43, James Yong a écrit : > >> >>> Hi all, > >> >>> > >> >>> How about hardcoding the released version in start.properties? > >> >>> E.g. > >> >>> ofbiz.version=v16.11.03 > >> >>> > >> >>> During startup, we can print out the version as part of the > >> >>> ____ __________ _ > >> >>> / __ \/ ____/ __ )(_)___ > >> >>> / / / / /_ / __ / /_ / > >> >>> / /_/ / __/ / /_/ / / / /_ > >> >>> \____/_/ /_____/_/ /___/ v16.11.03 is started and ready. > >> >>> > >> >>> Just update the released version in the properties before a release. > >> >>> > >> >>> Regards, > >> >>> James Yong > >> >>> > >> >>> > >> >>> On 2017-11-27 22:08, Akash Jain <[hidden email]> wrote: > >> >>>> +1, version information should available somewhere, it will be helpful. > >> >>>> > >> >>>> Thanks and Regards > >> >>>> -- > >> >>>> Akash Jain > >> >>>> > >> >>>> On Mon, Nov 27, 2017 at 6:07 PM, Sharan Foga <[hidden email]> wrote: > >> >>>> > >> >>>>> Hi > >> >>>>> > >> >>>>> Having the version info available somehow could be useful. Whenever a user > >> >>>>> reports a problem on our user lists, one of the first questions we ask them > >> >>>>> is "What version are you using?" > >> >>>>> > >> >>>>> Perhaps asking the question about version information, on the user list > >> >>>>> might help. > >> >>>>> > >> >>>>> Thanks > >> >>>>> Sharan > >> >>>>> > >> >>>>> On 2017-11-27 08:49, Pierre Smits <[hidden email]> wrote: > >> >>>>>> Hi Devanshu Vyas, > >> >>>>>> > >> >>>>>> Please see inline. > >> >>>>>> > >> >>>>>> Best regards, > >> >>>>>> > >> >>>>>> Pierre Smits > >> >>>>>> > >> >>>>>> ORRTIZ.COM <http://www.orrtiz.com> > >> >>>>>> OFBiz based solutions & services > >> >>>>>> > >> >>>>>> OEM - The OFBiz Extensions Marketplace1 > >> >>>>>> http://oem.ofbizci.net/oci-2/ > >> >>>>>> 1 not affiliated to (and not endorsed by) the OFBiz project > >> >>>>>> > >> >>>>>> On Mon, Nov 27, 2017 at 7:33 AM, Devanshu Vyas < > >> >>>>> [hidden email]> > >> >>>>>> wrote: > >> >>>>>> > >> >>>>>>> Thank you all for your thoughts on this. > >> >>>>>>> > >> >>>>>>> I really like the idea shared by Taher to create a version > >> >>>>>>> target and after second thought I agree that it can be a tiresome task > >> >>>>> to > >> >>>>>>> update version info manually with each release. > >> >>>>>>> But before we conclude this discussion, I would like to share another > >> >>>>>>> thought with you. I think we can add OFBiz version info in the > >> >>>>> licensing > >> >>>>>>> information we add to our files. > >> >>>>>>> I know it will be a manual task, but can be easily done with a simple > >> >>>>> Find > >> >>>>>>> & Replace. > >> >>>>>>> > >> >>>>>>> I am happy to work on the whichever implementation we decide > >> >>>>> here(hoping I > >> >>>>>>> am not stepping on anyone's toes). > >> >>>>>>> > >> >>>>>> Don't worry. I bet you aren't. ;) > >> >>>>>> > >> >>>>>> > >> >>>>>>> And my reason to raise the concern was that it is very > >> >>>>>>> identify which version of code a user is using(a real-time scenario > >> >>>>> where I > >> >>>>>>> was exposed to OFBiz code and I couldn't perform anything on it. So > >> >>>>> just by > >> >>>>>>> looking at it, I was unable to determine what version it was) > >> >>>>>>> > >> >>>>>>> > >> >>>>>> So you experienced a user being exposed to a OOTB OFBiz deployment, > >> >>>>>> deployed by your employer HotWax? Or was the user exposed to a deployment > >> >>>>>> that was also modified? In either case this is an issue related to the > >> >>>>>> Release Management process applied. And not necessarily an OFBIZ problem. > >> >>>>>> > >> >>>>>> > >> >>>>>>> Waiting for your replies!! > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> Thanks & Regards, > >> >>>>>>> Devanshu Vyas. > >> >>>>>>> > >> >> > >> > >> > |
-1 for storing the version in .properties.
+1 for using a VERSION or RELEASE file in the root folder to store this information. It's easily accessible, you cannot overlook it and the content can be read by any functionality. It can also be automatically set by (custom) builds to be generated. I think it might be a good idea to just render the version in the applications header or footer template as a HTML comment. Then it is viewable by anyone even if there is no access to the source. This should be made configurable in general.properties to prevent to show it if the user does not want this. Thanks and regards, Michael Am 29.11.17 um 07:38 schrieb Taher Alkhateeb: > Hi James, > > The purpose of Config.java is to configure critical server settings at > startup such as log location, admin settings, etc. These settings could be > also used in test.properties and load-data.properties and all such > properties get a default value if not set. > > OFBiz version by definition is not a startup parameter. It is not something > you need to set so that the system works correctly. It's only a piece of > information. That is why I suggested that it might not be a good fit for > start.properties and Config.java. It's also hard for users to find the > version if it is hidden somewhere like that. And given the nature of > verbose logging in OFBiz I suspect that it might not be very useful to spit > out OFBiz version in the logs because it will be lost in the mix. > > So if I may suggest maybe there are a few alternatives that could work like: > - adding it to another properties file like general.properties (although > still a bit hidden yet more related than start.properties) > - adding it to the UiLabelMap and putting it in the footer of the system > - putting it in a VERSION file or README.md as originally suggested > > I'm sure you can also come up with good ideas to that end, I'm just > thinking quickly of alternatives that might fit. > > On Nov 29, 2017 2:30 AM, "James Yong" <[hidden email]> wrote: > > Hi Taher, > > The reason of putting released version (e.g. 16.11.03) in start.properties > file is because the start program is already reading that file and that > info will be included in the startup message. Printing released version to > the console is in line with what other applications, like Tomcat, have been > doing. > > I haven't check how the start program will read the VERSION file but I have > no issue with this approach and we can further discuss how it can be done. > > Regards, > James Yong > > On 2017-11-29 02:51, Taher Alkhateeb <[hidden email]> wrote: >> Hi James, >> >> I'm not sure of the purpose of doing all of that? start.properties is >> a file to feed into Config.java which in turn configures the startup >> settings of OFBiz. The version has nothing with the startup code so it >> seems like an improper place to put the property and maybe it might >> confuse users. >> >> Also, why go through all this logic? why not simply create a VERSION >> file and place the version in it? Much simpler and easier if all you >> need is a version reference. Unless you want to introduce some logic? >> >> On Tue, Nov 28, 2017 at 6:04 PM, James Yong <[hidden email]> wrote: >>> Hi all, >>> >>> If there is no further discusson, I will create a JIRA issue later to >>> 1) add an ofbiz.version key in start.properties file; and >>> 2) have the ofbiz.version key value included in the startup message. >>> >>> Regards, >>> James Yong >>> >>> On 2017-11-28 01:35, Jacques Le Roux <[hidden email]> > wrote: >>>> OK then if we have both, why not? >>>> >>>> Jacques >>>> >>>> >>>> Le 27/11/2017 à 17:15, James Yong a écrit : >>>>> Hi Jacques, >>>>> >>>>> The developer can refer to the proposed ofbiz.version property if > needed. >>>>> Regards, >>>>> James Yong >>>>> >>>>> On 2017-11-28 00:03, Jacques Le Roux <[hidden email]> > wrote: >>>>>> Hi James, >>>>>> >>>>>> That's good when you start but could be hard to find after many > days running in production for instance >>>>>> Jacques >>>>>> >>>>>> >>>>>> Le 27/11/2017 à 15:43, James Yong a écrit : >>>>>>> Hi all, >>>>>>> >>>>>>> How about hardcoding the released version in start.properties? >>>>>>> E.g. >>>>>>> ofbiz.version=v16.11.03 >>>>>>> >>>>>>> During startup, we can print out the version as part of the > startup message like: >>>>>>> ____ __________ _ >>>>>>> / __ \/ ____/ __ )(_)___ >>>>>>> / / / / /_ / __ / /_ / >>>>>>> / /_/ / __/ / /_/ / / / /_ >>>>>>> \____/_/ /_____/_/ /___/ v16.11.03 is started and ready. >>>>>>> >>>>>>> Just update the released version in the properties before a > release. >>>>>>> Regards, >>>>>>> James Yong >>>>>>> >>>>>>> >>>>>>> On 2017-11-27 22:08, Akash Jain <[hidden email]> > wrote: >>>>>>>> +1, version information should available somewhere, it will be > helpful. >>>>>>>> Thanks and Regards >>>>>>>> -- >>>>>>>> Akash Jain >>>>>>>> >>>>>>>> On Mon, Nov 27, 2017 at 6:07 PM, Sharan Foga <[hidden email]> > wrote: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> Having the version info available somehow could be useful. > Whenever a user >>>>>>>>> reports a problem on our user lists, one of the first questions > we ask them >>>>>>>>> is "What version are you using?" >>>>>>>>> >>>>>>>>> Perhaps asking the question about version information, on the > user list >>>>>>>>> might help. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Sharan >>>>>>>>> >>>>>>>>> On 2017-11-27 08:49, Pierre Smits <[hidden email]> wrote: >>>>>>>>>> Hi Devanshu Vyas, >>>>>>>>>> >>>>>>>>>> Please see inline. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> >>>>>>>>>> Pierre Smits >>>>>>>>>> >>>>>>>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>>>>>>> OFBiz based solutions & services >>>>>>>>>> >>>>>>>>>> OEM - The OFBiz Extensions Marketplace1 >>>>>>>>>> http://oem.ofbizci.net/oci-2/ >>>>>>>>>> 1 not affiliated to (and not endorsed by) the OFBiz project >>>>>>>>>> >>>>>>>>>> On Mon, Nov 27, 2017 at 7:33 AM, Devanshu Vyas < >>>>>>>>> [hidden email]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Thank you all for your thoughts on this. >>>>>>>>>>> >>>>>>>>>>> I really like the idea shared by Taher to create a version > file using >>>>>>>>>>> target and after second thought I agree that it can be a > tiresome task >>>>>>>>> to >>>>>>>>>>> update version info manually with each release. >>>>>>>>>>> But before we conclude this discussion, I would like to share > another >>>>>>>>>>> thought with you. I think we can add OFBiz version info in the >>>>>>>>> licensing >>>>>>>>>>> information we add to our files. >>>>>>>>>>> I know it will be a manual task, but can be easily done with a > simple >>>>>>>>> Find >>>>>>>>>>> & Replace. >>>>>>>>>>> >>>>>>>>>>> I am happy to work on the whichever implementation we decide >>>>>>>>> here(hoping I >>>>>>>>>>> am not stepping on anyone's toes). >>>>>>>>>>> >>>>>>>>>> Don't worry. I bet you aren't. ;) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> And my reason to raise the concern was that it is very > difficult to >>>>>>>>>>> identify which version of code a user is using(a real-time > scenario >>>>>>>>> where I >>>>>>>>>>> was exposed to OFBiz code and I couldn't perform anything on > it. So >>>>>>>>> just by >>>>>>>>>>> looking at it, I was unable to determine what version it was) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> So you experienced a user being exposed to a OOTB OFBiz > deployment, >>>>>>>>>> deployed by your employer HotWax? Or was the user exposed to a > deployment >>>>>>>>>> that was also modified? In either case this is an issue related > to the >>>>>>>>>> Release Management process applied. And not necessarily an > OFBIZ problem. >>>>>>>>>> >>>>>>>>>>> Waiting for your replies!! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks & Regards, >>>>>>>>>>> Devanshu Vyas. >>>>>>>>>>> >>>> smime.p7s (5K) Download Attachment |
Administrator
|
Le 29/11/2017 à 07:57, Michael Brohl a écrit :
> -1 for storing the version in .properties. +1 > > +1 for using a VERSION or RELEASE file in the root folder to store this information. > It's easily accessible, you cannot overlook it and the content can be read by any functionality. It can also be automatically set by (custom) builds > to be generated. +1 > > I think it might be a good idea to just render the version in the applications header or footer template as a HTML comment. Then it is viewable by > anyone even if there is no access to the source. This should be made configurable in general.properties to prevent to show it if the user does not > want this. +1 Jacques > > Thanks and regards, > > Michael > > > Am 29.11.17 um 07:38 schrieb Taher Alkhateeb: >> Hi James, >> >> The purpose of Config.java is to configure critical server settings at >> startup such as log location, admin settings, etc. These settings could be >> also used in test.properties and load-data.properties and all such >> properties get a default value if not set. >> >> OFBiz version by definition is not a startup parameter. It is not something >> you need to set so that the system works correctly. It's only a piece of >> information. That is why I suggested that it might not be a good fit for >> start.properties and Config.java. It's also hard for users to find the >> version if it is hidden somewhere like that. And given the nature of >> verbose logging in OFBiz I suspect that it might not be very useful to spit >> out OFBiz version in the logs because it will be lost in the mix. >> >> So if I may suggest maybe there are a few alternatives that could work like: >> - adding it to another properties file like general.properties (although >> still a bit hidden yet more related than start.properties) >> - adding it to the UiLabelMap and putting it in the footer of the system >> - putting it in a VERSION file or README.md as originally suggested >> >> I'm sure you can also come up with good ideas to that end, I'm just >> thinking quickly of alternatives that might fit. >> >> On Nov 29, 2017 2:30 AM, "James Yong" <[hidden email]> wrote: >> >> Hi Taher, >> >> The reason of putting released version (e.g. 16.11.03) in start.properties >> file is because the start program is already reading that file and that >> info will be included in the startup message. Printing released version to >> the console is in line with what other applications, like Tomcat, have been >> doing. >> >> I haven't check how the start program will read the VERSION file but I have >> no issue with this approach and we can further discuss how it can be done. >> >> Regards, >> James Yong >> >> On 2017-11-29 02:51, Taher Alkhateeb <[hidden email]> wrote: >>> Hi James, >>> >>> I'm not sure of the purpose of doing all of that? start.properties is >>> a file to feed into Config.java which in turn configures the startup >>> settings of OFBiz. The version has nothing with the startup code so it >>> seems like an improper place to put the property and maybe it might >>> confuse users. >>> >>> Also, why go through all this logic? why not simply create a VERSION >>> file and place the version in it? Much simpler and easier if all you >>> need is a version reference. Unless you want to introduce some logic? >>> >>> On Tue, Nov 28, 2017 at 6:04 PM, James Yong <[hidden email]> wrote: >>>> Hi all, >>>> >>>> If there is no further discusson, I will create a JIRA issue later to >>>> 1) add an ofbiz.version key in start.properties file; and >>>> 2) have the ofbiz.version key value included in the startup message. >>>> >>>> Regards, >>>> James Yong >>>> >>>> On 2017-11-28 01:35, Jacques Le Roux <[hidden email]> >> wrote: >>>>> OK then if we have both, why not? >>>>> >>>>> Jacques >>>>> >>>>> >>>>> Le 27/11/2017 à 17:15, James Yong a écrit : >>>>>> Hi Jacques, >>>>>> >>>>>> The developer can refer to the proposed ofbiz.version property if >> needed. >>>>>> Regards, >>>>>> James Yong >>>>>> >>>>>> On 2017-11-28 00:03, Jacques Le Roux <[hidden email]> >> wrote: >>>>>>> Hi James, >>>>>>> >>>>>>> That's good when you start but could be hard to find after many >> days running in production for instance >>>>>>> Jacques >>>>>>> >>>>>>> >>>>>>> Le 27/11/2017 à 15:43, James Yong a écrit : >>>>>>>> Hi all, >>>>>>>> >>>>>>>> How about hardcoding the released version in start.properties? >>>>>>>> E.g. >>>>>>>> ofbiz.version=v16.11.03 >>>>>>>> >>>>>>>> During startup, we can print out the version as part of the >> startup message like: >>>>>>>> ____ __________ _ >>>>>>>> / __ \/ ____/ __ )(_)___ >>>>>>>> / / / / /_ / __ / /_ / >>>>>>>> / /_/ / __/ / /_/ / / / /_ >>>>>>>> \____/_/ /_____/_/ /___/ v16.11.03 is started and ready. >>>>>>>> >>>>>>>> Just update the released version in the properties before a >> release. >>>>>>>> Regards, >>>>>>>> James Yong >>>>>>>> >>>>>>>> >>>>>>>> On 2017-11-27 22:08, Akash Jain <[hidden email]> >> wrote: >>>>>>>>> +1, version information should available somewhere, it will be >> helpful. >>>>>>>>> Thanks and Regards >>>>>>>>> -- >>>>>>>>> Akash Jain >>>>>>>>> >>>>>>>>> On Mon, Nov 27, 2017 at 6:07 PM, Sharan Foga <[hidden email]> >> wrote: >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> Having the version info available somehow could be useful. >> Whenever a user >>>>>>>>>> reports a problem on our user lists, one of the first questions >> we ask them >>>>>>>>>> is "What version are you using?" >>>>>>>>>> >>>>>>>>>> Perhaps asking the question about version information, on the >> user list >>>>>>>>>> might help. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Sharan >>>>>>>>>> >>>>>>>>>> On 2017-11-27 08:49, Pierre Smits <[hidden email]> wrote: >>>>>>>>>>> Hi Devanshu Vyas, >>>>>>>>>>> >>>>>>>>>>> Please see inline. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> >>>>>>>>>>> Pierre Smits >>>>>>>>>>> >>>>>>>>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>>>>>>>> OFBiz based solutions & services >>>>>>>>>>> >>>>>>>>>>> OEM - The OFBiz Extensions Marketplace1 >>>>>>>>>>> http://oem.ofbizci.net/oci-2/ >>>>>>>>>>> 1 not affiliated to (and not endorsed by) the OFBiz project >>>>>>>>>>> >>>>>>>>>>> On Mon, Nov 27, 2017 at 7:33 AM, Devanshu Vyas < >>>>>>>>>> [hidden email]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Thank you all for your thoughts on this. >>>>>>>>>>>> >>>>>>>>>>>> I really like the idea shared by Taher to create a version >> file using >>>>>>>>>>>> target and after second thought I agree that it can be a >> tiresome task >>>>>>>>>> to >>>>>>>>>>>> update version info manually with each release. >>>>>>>>>>>> But before we conclude this discussion, I would like to share >> another >>>>>>>>>>>> thought with you. I think we can add OFBiz version info in the >>>>>>>>>> licensing >>>>>>>>>>>> information we add to our files. >>>>>>>>>>>> I know it will be a manual task, but can be easily done with a >> simple >>>>>>>>>> Find >>>>>>>>>>>> & Replace. >>>>>>>>>>>> >>>>>>>>>>>> I am happy to work on the whichever implementation we decide >>>>>>>>>> here(hoping I >>>>>>>>>>>> am not stepping on anyone's toes). >>>>>>>>>>>> >>>>>>>>>>> Don't worry. I bet you aren't. ;) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> And my reason to raise the concern was that it is very >> difficult to >>>>>>>>>>>> identify which version of code a user is using(a real-time >> scenario >>>>>>>>>> where I >>>>>>>>>>>> was exposed to OFBiz code and I couldn't perform anything on >> it. So >>>>>>>>>> just by >>>>>>>>>>>> looking at it, I was unable to determine what version it was) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> So you experienced a user being exposed to a OOTB OFBiz >> deployment, >>>>>>>>>>> deployed by your employer HotWax? Or was the user exposed to a >> deployment >>>>>>>>>>> that was also modified? In either case this is an issue related >> to the >>>>>>>>>>> Release Management process applied. And not necessarily an >> OFBIZ problem. >>>>>>>>>>> >>>>>>>>>>>> Waiting for your replies!! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks & Regards, >>>>>>>>>>>> Devanshu Vyas. >>>>>>>>>>>> >>>>> > > |
+1 to having VERSION file at project root to store released version.
On 2017-11-29 16:10, Jacques Le Roux <[hidden email]> wrote: > Le 29/11/2017 à 07:57, Michael Brohl a écrit : > > -1 for storing the version in .properties. > +1 > > > > > +1 for using a VERSION or RELEASE file in the root folder to store this information. > > It's easily accessible, you cannot overlook it and the content can be read by any functionality. It can also be automatically set by (custom) builds > > to be generated. > +1 > > > > > I think it might be a good idea to just render the version in the applications header or footer template as a HTML comment. Then it is viewable by > > anyone even if there is no access to the source. This should be made configurable in general.properties to prevent to show it if the user does not > > want this. > +1 > > Jacques > > > > Thanks and regards, > > > > Michael > > > > > > Am 29.11.17 um 07:38 schrieb Taher Alkhateeb: > >> Hi James, > >> > >> The purpose of Config.java is to configure critical server settings at > >> startup such as log location, admin settings, etc. These settings could be > >> also used in test.properties and load-data.properties and all such > >> properties get a default value if not set. > >> > >> OFBiz version by definition is not a startup parameter. It is not something > >> you need to set so that the system works correctly. It's only a piece of > >> information. That is why I suggested that it might not be a good fit for > >> start.properties and Config.java. It's also hard for users to find the > >> version if it is hidden somewhere like that. And given the nature of > >> verbose logging in OFBiz I suspect that it might not be very useful to spit > >> out OFBiz version in the logs because it will be lost in the mix. > >> > >> So if I may suggest maybe there are a few alternatives that could work like: > >> - adding it to another properties file like general.properties (although > >> still a bit hidden yet more related than start.properties) > >> - adding it to the UiLabelMap and putting it in the footer of the system > >> - putting it in a VERSION file or README.md as originally suggested > >> > >> I'm sure you can also come up with good ideas to that end, I'm just > >> thinking quickly of alternatives that might fit. > >> > >> On Nov 29, 2017 2:30 AM, "James Yong" <[hidden email]> wrote: > >> > >> Hi Taher, > >> > >> The reason of putting released version (e.g. 16.11.03) in start.properties > >> file is because the start program is already reading that file and that > >> info will be included in the startup message. Printing released version to > >> the console is in line with what other applications, like Tomcat, have been > >> doing. > >> > >> I haven't check how the start program will read the VERSION file but I have > >> no issue with this approach and we can further discuss how it can be done. > >> > >> Regards, > >> James Yong > >> > >> On 2017-11-29 02:51, Taher Alkhateeb <[hidden email]> wrote: > >>> Hi James, > >>> > >>> I'm not sure of the purpose of doing all of that? start.properties is > >>> a file to feed into Config.java which in turn configures the startup > >>> settings of OFBiz. The version has nothing with the startup code so it > >>> seems like an improper place to put the property and maybe it might > >>> confuse users. > >>> > >>> Also, why go through all this logic? why not simply create a VERSION > >>> file and place the version in it? Much simpler and easier if all you > >>> need is a version reference. Unless you want to introduce some logic? > >>> > >>> On Tue, Nov 28, 2017 at 6:04 PM, James Yong <[hidden email]> wrote: > >>>> Hi all, > >>>> > >>>> If there is no further discusson, I will create a JIRA issue later to > >>>> 1) add an ofbiz.version key in start.properties file; and > >>>> 2) have the ofbiz.version key value included in the startup message. > >>>> > >>>> Regards, > >>>> James Yong > >>>> > >>>> On 2017-11-28 01:35, Jacques Le Roux <[hidden email]> > >> wrote: > >>>>> OK then if we have both, why not? > >>>>> > >>>>> Jacques > >>>>> > >>>>> > >>>>> Le 27/11/2017 à 17:15, James Yong a écrit : > >>>>>> Hi Jacques, > >>>>>> > >>>>>> The developer can refer to the proposed ofbiz.version property if > >> needed. > >>>>>> Regards, > >>>>>> James Yong > >>>>>> > >>>>>> On 2017-11-28 00:03, Jacques Le Roux <[hidden email]> > >> wrote: > >>>>>>> Hi James, > >>>>>>> > >>>>>>> That's good when you start but could be hard to find after many > >> days running in production for instance > >>>>>>> Jacques > >>>>>>> > >>>>>>> > >>>>>>> Le 27/11/2017 à15:43, James Yong a écrità : > >>>>>>>> Hi all, > >>>>>>>> > >>>>>>>> How about hardcoding the released version in start.properties? > >>>>>>>> E.g. > >>>>>>>> ofbiz.version=v16.11.03 > >>>>>>>> > >>>>>>>> During startup, we can print out the version as part of the > >> startup message like: > >>>>>>>>      ____ __________ _ > >>>>>>>>     / __ \/ ____/ __ )(_)___ > >>>>>>>>    / / / / /_ / __ / /_ / > >>>>>>>> / /_/ / __/ / /_/ / / / /_ > >>>>>>>> \____/_/  /_____/_/ /___/ v16.11.03 is started and ready. > >>>>>>>> > >>>>>>>> Just update the released version in the properties before a > >> release. > >>>>>>>> Regards, > >>>>>>>> James Yong > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2017-11-27 22:08, Akash Jain <[hidden email]> > >> wrote: > >>>>>>>>> +1, version information should available somewhere, it will be > >> helpful. > >>>>>>>>> Thanks and Regards > >>>>>>>>> -- > >>>>>>>>> Akash Jain > >>>>>>>>> > >>>>>>>>> On Mon, Nov 27, 2017 at 6:07 PM, Sharan Foga <[hidden email]> > >> wrote: > >>>>>>>>>> Hi > >>>>>>>>>> > >>>>>>>>>> Having the version info available somehow could be useful. > >> Whenever a user > >>>>>>>>>> reports a problem on our user lists, one of the first questions > >> we ask them > >>>>>>>>>> is "What version are you using?" > >>>>>>>>>> > >>>>>>>>>> Perhaps asking the question about version information, on the > >> user list > >>>>>>>>>> might help. > >>>>>>>>>> > >>>>>>>>>> Thanks > >>>>>>>>>> Sharan > >>>>>>>>>> > >>>>>>>>>> On 2017-11-27 08:49, Pierre Smits <[hidden email]> wrote: > >>>>>>>>>>> Hi Devanshu Vyas, > >>>>>>>>>>> > >>>>>>>>>>> Please see inline. > >>>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> > >>>>>>>>>>> Pierre Smits > >>>>>>>>>>> > >>>>>>>>>>> ORRTIZ.COM <http://www.orrtiz.com> > >>>>>>>>>>> OFBiz based solutions & services > >>>>>>>>>>> > >>>>>>>>>>> OEM - The OFBiz Extensions Marketplace1 > >>>>>>>>>>> http://oem.ofbizci.net/oci-2/ > >>>>>>>>>>> 1 not affiliated to (and not endorsed by) the OFBiz project > >>>>>>>>>>> > >>>>>>>>>>> On Mon, Nov 27, 2017 at 7:33 AM, Devanshu Vyas < > >>>>>>>>>> [hidden email]> > >>>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Thank you all for your thoughts on this. > >>>>>>>>>>>> > >>>>>>>>>>>> I really like the idea shared by Taher to create a version > >> file using > >>>>>>>>>>>> target and after second thought I agree that it can be a > >> tiresome task > >>>>>>>>>> to > >>>>>>>>>>>> update version info manually with each release. > >>>>>>>>>>>> But before we conclude this discussion, I would like to share > >> another > >>>>>>>>>>>> thought with you. I think we can add OFBiz version info in the > >>>>>>>>>> licensing > >>>>>>>>>>>> information we add to our files. > >>>>>>>>>>>> I know it will be a manual task, but can be easily done with a > >> simple > >>>>>>>>>> Find > >>>>>>>>>>>> & Replace. > >>>>>>>>>>>> > >>>>>>>>>>>> I am happy to work on the whichever implementation we decide > >>>>>>>>>> here(hoping I > >>>>>>>>>>>> am not stepping on anyone's toes). > >>>>>>>>>>>> > >>>>>>>>>>> Don't worry. I bet you aren't. ;) > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> And my reason to raise the concern was that it is very > >> difficult to > >>>>>>>>>>>> identify which version of code a user is using(a real-time > >> scenario > >>>>>>>>>> where I > >>>>>>>>>>>> was exposed to OFBiz code and I couldn't perform anything on > >> it. So > >>>>>>>>>> just by > >>>>>>>>>>>> looking at it, I was unable to determine what version it was) > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> So you experienced a user being exposed to a OOTB OFBiz > >> deployment, > >>>>>>>>>>> deployed by your employer HotWax? Or was the user exposed to a > >> deployment > >>>>>>>>>>> that was also modified? In either case this is an issue related > >> to the > >>>>>>>>>>> Release Management process applied. And not necessarily an > >> OFBIZ problem. > >>>>>>>>>>> > >>>>>>>>>>>> Waiting for your replies!! > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks & Regards, > >>>>>>>>>>>> Devanshu Vyas. > >>>>>>>>>>>> > >>>>> > > > > > > |
Administrator
|
I created OFBIZ-10141 for that, please review
Jacques Le 30/11/2017 à 16:04, James Yong a écrit : > +1 to having VERSION file at project root to store released version. > > On 2017-11-29 16:10, Jacques Le Roux <[hidden email]> wrote: >> Le 29/11/2017 à 07:57, Michael Brohl a écrit : >>> -1 for storing the version in .properties. >> +1 >> >>> +1 for using a VERSION or RELEASE file in the root folder to store this information. >>> It's easily accessible, you cannot overlook it and the content can be read by any functionality. It can also be automatically set by (custom) builds >>> to be generated. >> +1 >> >>> I think it might be a good idea to just render the version in the applications header or footer template as a HTML comment. Then it is viewable by >>> anyone even if there is no access to the source. This should be made configurable in general.properties to prevent to show it if the user does not >>> want this. >> +1 >> >> Jacques >>> Thanks and regards, >>> >>> Michael >>> >>> >>> Am 29.11.17 um 07:38 schrieb Taher Alkhateeb: >>>> Hi James, >>>> >>>> The purpose of Config.java is to configure critical server settings at >>>> startup such as log location, admin settings, etc. These settings could be >>>> also used in test.properties and load-data.properties and all such >>>> properties get a default value if not set. >>>> >>>> OFBiz version by definition is not a startup parameter. It is not something >>>> you need to set so that the system works correctly. It's only a piece of >>>> information. That is why I suggested that it might not be a good fit for >>>> start.properties and Config.java. It's also hard for users to find the >>>> version if it is hidden somewhere like that. And given the nature of >>>> verbose logging in OFBiz I suspect that it might not be very useful to spit >>>> out OFBiz version in the logs because it will be lost in the mix. >>>> >>>> So if I may suggest maybe there are a few alternatives that could work like: >>>> - adding it to another properties file like general.properties (although >>>> still a bit hidden yet more related than start.properties) >>>> - adding it to the UiLabelMap and putting it in the footer of the system >>>> - putting it in a VERSION file or README.md as originally suggested >>>> >>>> I'm sure you can also come up with good ideas to that end, I'm just >>>> thinking quickly of alternatives that might fit. >>>> >>>> On Nov 29, 2017 2:30 AM, "James Yong" <[hidden email]> wrote: >>>> >>>> Hi Taher, >>>> >>>> The reason of putting released version (e.g. 16.11.03) in start.properties >>>> file is because the start program is already reading that file and that >>>> info will be included in the startup message. Printing released version to >>>> the console is in line with what other applications, like Tomcat, have been >>>> doing. >>>> >>>> I haven't check how the start program will read the VERSION file but I have >>>> no issue with this approach and we can further discuss how it can be done. >>>> >>>> Regards, >>>> James Yong >>>> >>>> On 2017-11-29 02:51, Taher Alkhateeb <[hidden email]> wrote: >>>>> Hi James, >>>>> >>>>> I'm not sure of the purpose of doing all of that? start.properties is >>>>> a file to feed into Config.java which in turn configures the startup >>>>> settings of OFBiz. The version has nothing with the startup code so it >>>>> seems like an improper place to put the property and maybe it might >>>>> confuse users. >>>>> >>>>> Also, why go through all this logic? why not simply create a VERSION >>>>> file and place the version in it? Much simpler and easier if all you >>>>> need is a version reference. Unless you want to introduce some logic? >>>>> >>>>> On Tue, Nov 28, 2017 at 6:04 PM, James Yong <[hidden email]> wrote: >>>>>> Hi all, >>>>>> >>>>>> If there is no further discusson, I will create a JIRA issue later to >>>>>> 1) add an ofbiz.version key in start.properties file; and >>>>>> 2) have the ofbiz.version key value included in the startup message. >>>>>> >>>>>> Regards, >>>>>> James Yong >>>>>> >>>>>> On 2017-11-28 01:35, Jacques Le Roux <[hidden email]> >>>> wrote: >>>>>>> OK then if we have both, why not? >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> >>>>>>> Le 27/11/2017 à 17:15, James Yong a écrit : >>>>>>>> Hi Jacques, >>>>>>>> >>>>>>>> The developer can refer to the proposed ofbiz.version property if >>>> needed. >>>>>>>> Regards, >>>>>>>> James Yong >>>>>>>> >>>>>>>> On 2017-11-28 00:03, Jacques Le Roux <[hidden email]> >>>> wrote: >>>>>>>>> Hi James, >>>>>>>>> >>>>>>>>> That's good when you start but could be hard to find after many >>>> days running in production for instance >>>>>>>>> Jacques >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 27/11/2017 à15:43, James Yong a écrit : >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> How about hardcoding the released version in start.properties? >>>>>>>>>> E.g. >>>>>>>>>> ofbiz.version=v16.11.03 >>>>>>>>>> >>>>>>>>>> During startup, we can print out the version as part of the >>>> startup message like: >>>>>>>>>>      ____ __________ _ >>>>>>>>>>     / __ \/ ____/ __ )(_)___ >>>>>>>>>>    / / / / /_ / __ / /_ / >>>>>>>>>> / /_/ / __/ / /_/ / / / /_ >>>>>>>>>> \____/_/  /_____/_/ /___/ v16.11.03 is started and ready. >>>>>>>>>> >>>>>>>>>> Just update the released version in the properties before a >>>> release. >>>>>>>>>> Regards, >>>>>>>>>> James Yong >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2017-11-27 22:08, Akash Jain <[hidden email]> >>>> wrote: >>>>>>>>>>> +1, version information should available somewhere, it will be >>>> helpful. >>>>>>>>>>> Thanks and Regards >>>>>>>>>>> -- >>>>>>>>>>> Akash Jain >>>>>>>>>>> >>>>>>>>>>> On Mon, Nov 27, 2017 at 6:07 PM, Sharan Foga <[hidden email]> >>>> wrote: >>>>>>>>>>>> Hi >>>>>>>>>>>> >>>>>>>>>>>> Having the version info available somehow could be useful. >>>> Whenever a user >>>>>>>>>>>> reports a problem on our user lists, one of the first questions >>>> we ask them >>>>>>>>>>>> is "What version are you using?" >>>>>>>>>>>> >>>>>>>>>>>> Perhaps asking the question about version information, on the >>>> user list >>>>>>>>>>>> might help. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Sharan >>>>>>>>>>>> >>>>>>>>>>>> On 2017-11-27 08:49, Pierre Smits <[hidden email]> wrote: >>>>>>>>>>>>> Hi Devanshu Vyas, >>>>>>>>>>>>> >>>>>>>>>>>>> Please see inline. >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Pierre Smits >>>>>>>>>>>>> >>>>>>>>>>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>>>>>>>>>> OFBiz based solutions & services >>>>>>>>>>>>> >>>>>>>>>>>>> OEM - The OFBiz Extensions Marketplace1 >>>>>>>>>>>>> http://oem.ofbizci.net/oci-2/ >>>>>>>>>>>>> 1 not affiliated to (and not endorsed by) the OFBiz project >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Nov 27, 2017 at 7:33 AM, Devanshu Vyas < >>>>>>>>>>>> [hidden email]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you all for your thoughts on this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I really like the idea shared by Taher to create a version >>>> file using >>>>>>>>>>>>>> target and after second thought I agree that it can be a >>>> tiresome task >>>>>>>>>>>> to >>>>>>>>>>>>>> update version info manually with each release. >>>>>>>>>>>>>> But before we conclude this discussion, I would like to share >>>> another >>>>>>>>>>>>>> thought with you. I think we can add OFBiz version info in the >>>>>>>>>>>> licensing >>>>>>>>>>>>>> information we add to our files. >>>>>>>>>>>>>> I know it will be a manual task, but can be easily done with a >>>> simple >>>>>>>>>>>> Find >>>>>>>>>>>>>> & Replace. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am happy to work on the whichever implementation we decide >>>>>>>>>>>> here(hoping I >>>>>>>>>>>>>> am not stepping on anyone's toes). >>>>>>>>>>>>>> >>>>>>>>>>>>> Don't worry. I bet you aren't. ;) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> And my reason to raise the concern was that it is very >>>> difficult to >>>>>>>>>>>>>> identify which version of code a user is using(a real-time >>>> scenario >>>>>>>>>>>> where I >>>>>>>>>>>>>> was exposed to OFBiz code and I couldn't perform anything on >>>> it. So >>>>>>>>>>>> just by >>>>>>>>>>>>>> looking at it, I was unable to determine what version it was) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> So you experienced a user being exposed to a OOTB OFBiz >>>> deployment, >>>>>>>>>>>>> deployed by your employer HotWax? Or was the user exposed to a >>>> deployment >>>>>>>>>>>>> that was also modified? In either case this is an issue related >>>> to the >>>>>>>>>>>>> Release Management process applied. And not necessarily an >>>> OFBIZ problem. >>>>>>>>>>>>>> Waiting for your replies!! >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks & Regards, >>>>>>>>>>>>>> Devanshu Vyas. >>>>>>>>>>>>>> >>> >> |
Free forum by Nabble | Edit this page |