You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ja...@hotwaxmedia.com> on 2014/08/19 15:34:49 UTC

Preparing for the 13.07.01 release

Before I start the process of preparing the release files for the first release of the 13.07 series and call a vote on it I would like to get your feedback on a couple of topics.

Should we backport to it the recent switch to Java 7?
Should we backport to it the recent update to Log4j2?

The main reason I am asking this is that once we release the first release out of 13.07, for sure we will not backport the aforementioned upgrades (because they are not bugs); however the 13.07 releases will stay with us for at least 2 years and it would be nice to do the migration to these new technologies now.

Thanks in advance,

Jacopo

Re: Preparing for the 13.07.01 release

Posted by Jacques Le Roux <ja...@les7arts.com>.

BTW about log4j2 https://issues.apache.org/jira/browse/LOG4J2/?selectedTab=com.atlassian.jira.jira-projects-plugin:changelog-panel

Jacques

Le 20/08/2014 20:54, Ron Wheeler a écrit :
> Thanks to everyone for these details.
>
> Ron
> On 20/08/2014 2:09 PM, Jacques Le Roux wrote:
>> And to conclude on this, though it's obvious, official release or whatever your are never sure that there are no bugs somewhere.
>> Just that older a release is (aka higher is its minor release number) the less bugs there are (also the less features, compared to a branch freezed 
>> later ;).
>>
>> The demo has nothing to do with releasing. It was just an argument to say that we are pretty confident of the branch after one year strengthening 
>> it, at least enough to using it as a "stable" demo.
>> We could have even decided then to release the R13.07 branch, we discussed it, by the way.
>>
>> Jacques
>>
>> Le 20/08/2014 17:53, Adrian Crum a écrit :
>>> And just to make sure there is no confusion, there is very little difference between the release branch and the release binary.
>>>
>>> If I download the release binary and unzip it, then check out the latest release branch, I will have two copies of basically the same thing.
>>>
>>> A release binary is not "more stable" than the branch, and the branch is not "less stable" than the release binary - as some have suggested.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 8/20/2014 4:38 PM, Jacopo Cappellato wrote:
>>>> 13.07 is just a release branch for now, that we are stabilizing since July 2013 (when we branched it from trunk); no release yet was made... when 
>>>> we will release 13.07.01 that will be the first stable release.
>>>>
>>>> Jacopo
>>>>
>>>> On Aug 20, 2014, at 5:08 PM, Ron Wheeler <rw...@artifact-software.com> wrote:
>>>>
>>>>> I guess that I am still a little confused about the release policy.
>>>>>
>>>>> If 13.07 was frozen in July 2013 with all of the functionality defined, what was the date that it was "released" with the database fixed and the 
>>>>> code "done" except for bug fixes (stable release?)?
>>>>>
>>>>> I am not sure that as a system admin, I would make the jump from someone putting a demo and me putting it into production.
>>>>>
>>>>> Was there a date that the development team said that it was now "recommended" for production use even though there were known bugs and a 
>>>>> 13.07.01 release was scheduled in the future.
>>>>> How can one know which 13.07 pre-release one has?
>>>>>
>>>>> Was this made available as a 13.07.00 or as a 13.07.01-SNAPSHOT?
>>>>>
>>>>> Ron
>>>>>
>>>>> On 19/08/2014 4:30 PM, Jacques Le Roux wrote:
>>>>>>
>>>>>> Le 19/08/2014 18:27, Ron Wheeler a écrit :
>>>>>>> On 19/08/2014 10:59 AM, Adrian Crum wrote:
>>>>>>>> Inline...
>>>>>>>>
>>>>>>>> Adrian Crum
>>>>>>>> Sandglass Software
>>>>>>>> www.sandglass-software.com
>>>>>>>>
>>>>>>>> On 8/19/2014 3:45 PM, Ron Wheeler wrote:
>>>>>>>>> Java 6 is already 8 years old. Java 7 is 3 years old. Java 8 is pretty
>>>>>>>>> new but worth considering if it is not a significant different from the
>>>>>>>>> upgrade to Java 7.
>>>>>>>>>
>>>>>>>>> How much work was involved in the switch from 6 to 7.
>>>>>>>>
>>>>>>>>
>>>>>>>> Unit tests fail in Java 7. They had to be modified.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The difference between versions of Log4j would not seem to be a big
>>>>>>>>> advantage or a big problem. I did this on one of our projects and it was
>>>>>>>>> pretty painless. I also switched from properties to xml and that was a 1
>>>>>>>>> hour project for my simple system.
>>>>>>>>>
>>>>>>>>>  From a marketing/project adoption point of view, a product based on an
>>>>>>>>> 8 year old version of Java is a lot less attractive that one running on
>>>>>>>>> the latest version.
>>>>>>>>> It shows that the project team is on top of current technology and that
>>>>>>>>> the project is active.
>>>>>>>>> I don't think that people would care much about the version of log4j
>>>>>>>>> when deciding whether to consider OfBiz.
>>>>>>>>
>>>>>>>>
>>>>>>>> True, that shouldn't affect those considering OFBiz. But sys admins configure tools to analyze OFBiz logs, and the new format could break 
>>>>>>>> those tools.
>>>>>>>> Keep in mind there may be hundreds of production deployments running on the R13 branch.
>>>>>>>>
>>>>>>> I thought that we are talking about the .01 release of 13.07.
>>>>>>> Putting milestones or development trunks into production does entail some risk.
>>>>>>> I am surprised that there are that many different system integrators or end-users that would put a development branch into production.
>>>>>>> End-users are usually bound by corporate policies about using official releases.
>>>>>>
>>>>>> Remember that the R13.07 branch has been freezed since , er, 13/07. So those people don't take much risks. There is always a trade between 
>>>>>> official and efficient.
>>>>>>
>>>>>>>
>>>>>>> I could imagine a few system integrators doing it for many clients but that means that only a few people would actually be affected as tool 
>>>>>>> providers.
>>>>>>>
>>>>>>>
>>>>>>>> Those sys admins could configure the new logger to produce logs that look like the old ones, but then that's extra work that they believe 
>>>>>>>> they shouldn't have to do on a "stable" release, and so forth and so on...
>>>>>>> I was not aware that 13.07 had a "stable" release so far.
>>>>>>
>>>>>> Not officially, but you maybe noticed that the stable demo runs 13.07.
>>>>>>
>>>>>>> They knew that there where many risks and potential costs associated with using a development trunk in production.
>>>>>>
>>>>>> It's not a development trunk, only bug fixed are committed once a branch is freezed
>>>>>>
>>>>>>> Perhaps a change of this nature is at the edge of the normal risks but it is clearly within the realm of possibility.
>>>>>>> Database changes, configuration setting changes, UI changes would be harder to deal with but are part of the risk of putting development into 
>>>>>>> production.
>>>>>>
>>>>>> Nope, you can be reassured no new features, improvements will be normally committed to a freezed branch.
>>>>>> That's why Jacopo asked about Java 7 and log4j2. Both are not risky at all, so I think it's possible to add them.
>>>>>>
>>>>>>> On the good side, they already have 13.07 so they can continue to run on their fork until they have worked out their upgrade process.
>>>>>>>
>>>>>>> Can the configuration of the logs be documented as a cookbook or an alternate log4j.xml to reduce the effort if it affects so many?
>>>>>>
>>>>>> There is only that for now 
>>>>>> https://cwiki.apache.org/confluence/display/OFBTECH/Apache+OFBiz+Technical+Production+Setup+Guide#ApacheOFBizTechnicalProductionSetupGuide-DebugSettings
>>>>>> But I guess it's enough for most of us
>>>>>>
>>>>>>>
>>>>>>> One would hope that the sysadmin tools are pretty flexible and not tied to a specific logger or worse a specific log format.
>>>>>>
>>>>>> I hope so
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>>
>>>>>>> Ron
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have not tried Java 8 so I can not comment on where problems can come
>>>>>>>>> from.
>>>>>>>>> Our move from 6 to 7 was pretty transparent but we did not have any code
>>>>>>>>> developed with earlier versions of Java and did not try to retrofit new
>>>>>>>>> Java 7 capabilities into existing code.
>>>>>>>>
>>>>>>>>
>>>>>>>> There is no Java 7 specific code in the trunk. The recent changes were merely fixing compatibility issues with Java 6.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> You have already done this so you know the extent of the effort required.
>>>>>>>>> I don't have to do the work so.....
>>>>>>>>>
>>>>>>>>> Ron
>>>>>>>>>
>>>>>>>>> On 19/08/2014 10:16 AM, Adrian Crum wrote:
>>>>>>>>>> I don't have an opinion on this.
>>>>>>>>>>
>>>>>>>>>> The "rule" has been to keep backports restricted to bug fixes only,
>>>>>>>>>> but we have a history of backporting various refactorings to make
>>>>>>>>>> branch maintenance easier.
>>>>>>>>>>
>>>>>>>>>>  From my perspective, the two things cancel each other out, and I end
>>>>>>>>>> up with no opinion.
>>>>>>>>>>
>>>>>>>>>> Adrian Crum
>>>>>>>>>> Sandglass Software
>>>>>>>>>> www.sandglass-software.com
>>>>>>>>>>
>>>>>>>>>> On 8/19/2014 2:34 PM, Jacopo Cappellato wrote:
>>>>>>>>>>> Before I start the process of preparing the release files for the
>>>>>>>>>>> first release of the 13.07 series and call a vote on it I would like
>>>>>>>>>>> to get your feedback on a couple of topics.
>>>>>>>>>>>
>>>>>>>>>>> Should we backport to it the recent switch to Java 7?
>>>>>>>>>>> Should we backport to it the recent update to Log4j2?
>>>>>>>>>>>
>>>>>>>>>>> The main reason I am asking this is that once we release the first
>>>>>>>>>>> release out of 13.07, for sure we will not backport the
>>>>>>>>>>> aforementioned upgrades (because they are not bugs); however the
>>>>>>>>>>> 13.07 releases will stay with us for at least 2 years and it would be
>>>>>>>>>>> nice to do the migration to these new technologies now.
>>>>>>>>>>>
>>>>>>>>>>> Thanks in advance,
>>>>>>>>>>>
>>>>>>>>>>> Jacopo
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Ron Wheeler
>>>>> President
>>>>> Artifact Software Inc
>>>>> email: rwheeler@artifact-software.com
>>>>> skype: ronaldmwheeler
>>>>> phone: 866-970-2435, ext 102
>>>>>
>>>>
>>>
>>
>
>

Re: Preparing for the 13.07.01 release

Posted by Ron Wheeler <rw...@artifact-software.com>.

Thanks to everyone for these details.

Ron
On 20/08/2014 2:09 PM, Jacques Le Roux wrote:
> And to conclude on this, though it's obvious, official release or 
> whatever your are never sure that there are no bugs somewhere.
> Just that older a release is (aka higher is its minor release number) 
> the less bugs there are (also the less features, compared to a branch 
> freezed later ;).
>
> The demo has nothing to do with releasing. It was just an argument to 
> say that we are pretty confident of the branch after one year 
> strengthening it, at least enough to using it as a "stable" demo.
> We could have even decided then to release the R13.07 branch, we 
> discussed it, by the way.
>
> Jacques
>
> Le 20/08/2014 17:53, Adrian Crum a écrit :
>> And just to make sure there is no confusion, there is very little 
>> difference between the release branch and the release binary.
>>
>> If I download the release binary and unzip it, then check out the 
>> latest release branch, I will have two copies of basically the same 
>> thing.
>>
>> A release binary is not "more stable" than the branch, and the branch 
>> is not "less stable" than the release binary - as some have suggested.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 8/20/2014 4:38 PM, Jacopo Cappellato wrote:
>>> 13.07 is just a release branch for now, that we are stabilizing 
>>> since July 2013 (when we branched it from trunk); no release yet was 
>>> made... when we will release 13.07.01 that will be the first stable 
>>> release.
>>>
>>> Jacopo
>>>
>>> On Aug 20, 2014, at 5:08 PM, Ron Wheeler 
>>> <rw...@artifact-software.com> wrote:
>>>
>>>> I guess that I am still a little confused about the release policy.
>>>>
>>>> If 13.07 was frozen in July 2013 with all of the functionality 
>>>> defined, what was the date that it was "released" with the database 
>>>> fixed and the code "done" except for bug fixes (stable release?)?
>>>>
>>>> I am not sure that as a system admin, I would make the jump from 
>>>> someone putting a demo and me putting it into production.
>>>>
>>>> Was there a date that the development team said that it was now 
>>>> "recommended" for production use even though there were known bugs 
>>>> and a 13.07.01 release was scheduled in the future.
>>>> How can one know which 13.07 pre-release one has?
>>>>
>>>> Was this made available as a 13.07.00 or as a 13.07.01-SNAPSHOT?
>>>>
>>>> Ron
>>>>
>>>> On 19/08/2014 4:30 PM, Jacques Le Roux wrote:
>>>>>
>>>>> Le 19/08/2014 18:27, Ron Wheeler a écrit :
>>>>>> On 19/08/2014 10:59 AM, Adrian Crum wrote:
>>>>>>> Inline...
>>>>>>>
>>>>>>> Adrian Crum
>>>>>>> Sandglass Software
>>>>>>> www.sandglass-software.com
>>>>>>>
>>>>>>> On 8/19/2014 3:45 PM, Ron Wheeler wrote:
>>>>>>>> Java 6 is already 8 years old. Java 7 is 3 years old. Java 8 is 
>>>>>>>> pretty
>>>>>>>> new but worth considering if it is not a significant different 
>>>>>>>> from the
>>>>>>>> upgrade to Java 7.
>>>>>>>>
>>>>>>>> How much work was involved in the switch from 6 to 7.
>>>>>>>
>>>>>>>
>>>>>>> Unit tests fail in Java 7. They had to be modified.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> The difference between versions of Log4j would not seem to be a 
>>>>>>>> big
>>>>>>>> advantage or a big problem. I did this on one of our projects 
>>>>>>>> and it was
>>>>>>>> pretty painless. I also switched from properties to xml and 
>>>>>>>> that was a 1
>>>>>>>> hour project for my simple system.
>>>>>>>>
>>>>>>>>  From a marketing/project adoption point of view, a product 
>>>>>>>> based on an
>>>>>>>> 8 year old version of Java is a lot less attractive that one 
>>>>>>>> running on
>>>>>>>> the latest version.
>>>>>>>> It shows that the project team is on top of current technology 
>>>>>>>> and that
>>>>>>>> the project is active.
>>>>>>>> I don't think that people would care much about the version of 
>>>>>>>> log4j
>>>>>>>> when deciding whether to consider OfBiz.
>>>>>>>
>>>>>>>
>>>>>>> True, that shouldn't affect those considering OFBiz. But sys 
>>>>>>> admins configure tools to analyze OFBiz logs, and the new format 
>>>>>>> could break those tools.
>>>>>>> Keep in mind there may be hundreds of production deployments 
>>>>>>> running on the R13 branch.
>>>>>>>
>>>>>> I thought that we are talking about the .01 release of 13.07.
>>>>>> Putting milestones or development trunks into production does 
>>>>>> entail some risk.
>>>>>> I am surprised that there are that many different system 
>>>>>> integrators or end-users that would put a development branch into 
>>>>>> production.
>>>>>> End-users are usually bound by corporate policies about using 
>>>>>> official releases.
>>>>>
>>>>> Remember that the R13.07 branch has been freezed since , er, 
>>>>> 13/07. So those people don't take much risks. There is always a 
>>>>> trade between official and efficient.
>>>>>
>>>>>>
>>>>>> I could imagine a few system integrators doing it for many 
>>>>>> clients but that means that only a few people would actually be 
>>>>>> affected as tool providers.
>>>>>>
>>>>>>
>>>>>>> Those sys admins could configure the new logger to produce logs 
>>>>>>> that look like the old ones, but then that's extra work that 
>>>>>>> they believe they shouldn't have to do on a "stable" release, 
>>>>>>> and so forth and so on...
>>>>>> I was not aware that 13.07 had a "stable" release so far.
>>>>>
>>>>> Not officially, but you maybe noticed that the stable demo runs 
>>>>> 13.07.
>>>>>
>>>>>> They knew that there where many risks and potential costs 
>>>>>> associated with using a development trunk in production.
>>>>>
>>>>> It's not a development trunk, only bug fixed are committed once a 
>>>>> branch is freezed
>>>>>
>>>>>> Perhaps a change of this nature is at the edge of the normal 
>>>>>> risks but it is clearly within the realm of possibility.
>>>>>> Database changes, configuration setting changes, UI changes would 
>>>>>> be harder to deal with but are part of the risk of putting 
>>>>>> development into production.
>>>>>
>>>>> Nope, you can be reassured no new features, improvements will be 
>>>>> normally committed to a freezed branch.
>>>>> That's why Jacopo asked about Java 7 and log4j2. Both are not 
>>>>> risky at all, so I think it's possible to add  them.
>>>>>
>>>>>> On the good side, they already have 13.07 so they can continue to 
>>>>>> run on their fork until they have worked out their upgrade process.
>>>>>>
>>>>>> Can the configuration of the logs be documented as a cookbook or 
>>>>>> an alternate log4j.xml to reduce the effort if it affects so many?
>>>>>
>>>>> There is only that for now 
>>>>> https://cwiki.apache.org/confluence/display/OFBTECH/Apache+OFBiz+Technical+Production+Setup+Guide#ApacheOFBizTechnicalProductionSetupGuide-DebugSettings
>>>>> But I guess it's enough for most of us
>>>>>
>>>>>>
>>>>>> One would hope that the sysadmin tools are pretty flexible and 
>>>>>> not tied to a specific logger or worse a specific log format.
>>>>>
>>>>> I hope so
>>>>>
>>>>> Jacques
>>>>>
>>>>>>
>>>>>> Ron
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> I have not tried Java 8 so I can not comment on where problems 
>>>>>>>> can come
>>>>>>>> from.
>>>>>>>> Our move from 6 to 7 was pretty transparent but we did not have 
>>>>>>>> any code
>>>>>>>> developed with earlier versions of Java and did not try to 
>>>>>>>> retrofit new
>>>>>>>> Java 7 capabilities into existing code.
>>>>>>>
>>>>>>>
>>>>>>> There is no Java 7 specific code in the trunk. The recent 
>>>>>>> changes were merely fixing compatibility issues with Java 6.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> You have already done this so you know the extent of the effort 
>>>>>>>> required.
>>>>>>>> I don't have to do the work so.....
>>>>>>>>
>>>>>>>> Ron
>>>>>>>>
>>>>>>>> On 19/08/2014 10:16 AM, Adrian Crum wrote:
>>>>>>>>> I don't have an opinion on this.
>>>>>>>>>
>>>>>>>>> The "rule" has been to keep backports restricted to bug fixes 
>>>>>>>>> only,
>>>>>>>>> but we have a history of backporting various refactorings to make
>>>>>>>>> branch maintenance easier.
>>>>>>>>>
>>>>>>>>>  From my perspective, the two things cancel each other out, 
>>>>>>>>> and I end
>>>>>>>>> up with no opinion.
>>>>>>>>>
>>>>>>>>> Adrian Crum
>>>>>>>>> Sandglass Software
>>>>>>>>> www.sandglass-software.com
>>>>>>>>>
>>>>>>>>> On 8/19/2014 2:34 PM, Jacopo Cappellato wrote:
>>>>>>>>>> Before I start the process of preparing the release files for 
>>>>>>>>>> the
>>>>>>>>>> first release of the 13.07 series and call a vote on it I 
>>>>>>>>>> would like
>>>>>>>>>> to get your feedback on a couple of topics.
>>>>>>>>>>
>>>>>>>>>> Should we backport to it the recent switch to Java 7?
>>>>>>>>>> Should we backport to it the recent update to Log4j2?
>>>>>>>>>>
>>>>>>>>>> The main reason I am asking this is that once we release the 
>>>>>>>>>> first
>>>>>>>>>> release out of 13.07, for sure we will not backport the
>>>>>>>>>> aforementioned upgrades (because they are not bugs); however the
>>>>>>>>>> 13.07 releases will stay with us for at least 2 years and it 
>>>>>>>>>> would be
>>>>>>>>>> nice to do the migration to these new technologies now.
>>>>>>>>>>
>>>>>>>>>> Thanks in advance,
>>>>>>>>>>
>>>>>>>>>> Jacopo
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Ron Wheeler
>>>> President
>>>> Artifact Software Inc
>>>> email: rwheeler@artifact-software.com
>>>> skype: ronaldmwheeler
>>>> phone: 866-970-2435, ext 102
>>>>
>>>
>>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Preparing for the 13.07.01 release

Posted by Jacques Le Roux <ja...@les7arts.com>.

And to conclude on this, though it's obvious, official release or whatever your are never sure that there are no bugs somewhere.
Just that older a release is (aka higher is its minor release number) the less bugs there are (also the less features, compared to a branch freezed 
later ;).

The demo has nothing to do with releasing. It was just an argument to say that we are pretty confident of the branch after one year strengthening it, 
at least enough to using it as a "stable" demo.
We could have even decided then to release the R13.07 branch, we discussed it, by the way.

Jacques

Le 20/08/2014 17:53, Adrian Crum a écrit :
> And just to make sure there is no confusion, there is very little difference between the release branch and the release binary.
>
> If I download the release binary and unzip it, then check out the latest release branch, I will have two copies of basically the same thing.
>
> A release binary is not "more stable" than the branch, and the branch is not "less stable" than the release binary - as some have suggested.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 8/20/2014 4:38 PM, Jacopo Cappellato wrote:
>> 13.07 is just a release branch for now, that we are stabilizing since July 2013 (when we branched it from trunk); no release yet was made... when 
>> we will release 13.07.01 that will be the first stable release.
>>
>> Jacopo
>>
>> On Aug 20, 2014, at 5:08 PM, Ron Wheeler <rw...@artifact-software.com> wrote:
>>
>>> I guess that I am still a little confused about the release policy.
>>>
>>> If 13.07 was frozen in July 2013 with all of the functionality defined, what was the date that it was "released" with the database fixed and the 
>>> code "done" except for bug fixes (stable release?)?
>>>
>>> I am not sure that as a system admin, I would make the jump from someone putting a demo and me putting it into production.
>>>
>>> Was there a date that the development team said that it was now "recommended" for production use even though there were known bugs and a 13.07.01 
>>> release was scheduled in the future.
>>> How can one know which 13.07 pre-release one has?
>>>
>>> Was this made available as a 13.07.00 or as a 13.07.01-SNAPSHOT?
>>>
>>> Ron
>>>
>>> On 19/08/2014 4:30 PM, Jacques Le Roux wrote:
>>>>
>>>> Le 19/08/2014 18:27, Ron Wheeler a écrit :
>>>>> On 19/08/2014 10:59 AM, Adrian Crum wrote:
>>>>>> Inline...
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>> On 8/19/2014 3:45 PM, Ron Wheeler wrote:
>>>>>>> Java 6 is already 8 years old. Java 7 is 3 years old. Java 8 is pretty
>>>>>>> new but worth considering if it is not a significant different from the
>>>>>>> upgrade to Java 7.
>>>>>>>
>>>>>>> How much work was involved in the switch from 6 to 7.
>>>>>>
>>>>>>
>>>>>> Unit tests fail in Java 7. They had to be modified.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> The difference between versions of Log4j would not seem to be a big
>>>>>>> advantage or a big problem. I did this on one of our projects and it was
>>>>>>> pretty painless. I also switched from properties to xml and that was a 1
>>>>>>> hour project for my simple system.
>>>>>>>
>>>>>>>  From a marketing/project adoption point of view, a product based on an
>>>>>>> 8 year old version of Java is a lot less attractive that one running on
>>>>>>> the latest version.
>>>>>>> It shows that the project team is on top of current technology and that
>>>>>>> the project is active.
>>>>>>> I don't think that people would care much about the version of log4j
>>>>>>> when deciding whether to consider OfBiz.
>>>>>>
>>>>>>
>>>>>> True, that shouldn't affect those considering OFBiz. But sys admins configure tools to analyze OFBiz logs, and the new format could break those 
>>>>>> tools.
>>>>>> Keep in mind there may be hundreds of production deployments running on the R13 branch.
>>>>>>
>>>>> I thought that we are talking about the .01 release of 13.07.
>>>>> Putting milestones or development trunks into production does entail some risk.
>>>>> I am surprised that there are that many different system integrators or end-users that would put a development branch into production.
>>>>> End-users are usually bound by corporate policies about using official releases.
>>>>
>>>> Remember that the R13.07 branch has been freezed since , er, 13/07. So those people don't take much risks. There is always a trade between 
>>>> official and efficient.
>>>>
>>>>>
>>>>> I could imagine a few system integrators doing it for many clients but that means that only a few people would actually be affected as tool 
>>>>> providers.
>>>>>
>>>>>
>>>>>> Those sys admins could configure the new logger to produce logs that look like the old ones, but then that's extra work that they believe they 
>>>>>> shouldn't have to do on a "stable" release, and so forth and so on...
>>>>> I was not aware that 13.07 had a "stable" release so far.
>>>>
>>>> Not officially, but you maybe noticed that the stable demo runs 13.07.
>>>>
>>>>> They knew that there where many risks and potential costs associated with using a development trunk in production.
>>>>
>>>> It's not a development trunk, only bug fixed are committed once a branch is freezed
>>>>
>>>>> Perhaps a change of this nature is at the edge of the normal risks but it is clearly within the realm of possibility.
>>>>> Database changes, configuration setting changes, UI changes would be harder to deal with but are part of the risk of putting development into 
>>>>> production.
>>>>
>>>> Nope, you can be reassured no new features, improvements will be normally committed to a freezed branch.
>>>> That's why Jacopo asked about Java 7 and log4j2. Both are not risky at all, so I think it's possible to add  them.
>>>>
>>>>> On the good side, they already have 13.07 so they can continue to run on their fork until they have worked out their upgrade process.
>>>>>
>>>>> Can the configuration of the logs be documented as a cookbook or an alternate log4j.xml to reduce the effort if it affects so many?
>>>>
>>>> There is only that for now 
>>>> https://cwiki.apache.org/confluence/display/OFBTECH/Apache+OFBiz+Technical+Production+Setup+Guide#ApacheOFBizTechnicalProductionSetupGuide-DebugSettings
>>>> But I guess it's enough for most of us
>>>>
>>>>>
>>>>> One would hope that the sysadmin tools are pretty flexible and not tied to a specific logger or worse a specific log format.
>>>>
>>>> I hope so
>>>>
>>>> Jacques
>>>>
>>>>>
>>>>> Ron
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> I have not tried Java 8 so I can not comment on where problems can come
>>>>>>> from.
>>>>>>> Our move from 6 to 7 was pretty transparent but we did not have any code
>>>>>>> developed with earlier versions of Java and did not try to retrofit new
>>>>>>> Java 7 capabilities into existing code.
>>>>>>
>>>>>>
>>>>>> There is no Java 7 specific code in the trunk. The recent changes were merely fixing compatibility issues with Java 6.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> You have already done this so you know the extent of the effort required.
>>>>>>> I don't have to do the work so.....
>>>>>>>
>>>>>>> Ron
>>>>>>>
>>>>>>> On 19/08/2014 10:16 AM, Adrian Crum wrote:
>>>>>>>> I don't have an opinion on this.
>>>>>>>>
>>>>>>>> The "rule" has been to keep backports restricted to bug fixes only,
>>>>>>>> but we have a history of backporting various refactorings to make
>>>>>>>> branch maintenance easier.
>>>>>>>>
>>>>>>>>  From my perspective, the two things cancel each other out, and I end
>>>>>>>> up with no opinion.
>>>>>>>>
>>>>>>>> Adrian Crum
>>>>>>>> Sandglass Software
>>>>>>>> www.sandglass-software.com
>>>>>>>>
>>>>>>>> On 8/19/2014 2:34 PM, Jacopo Cappellato wrote:
>>>>>>>>> Before I start the process of preparing the release files for the
>>>>>>>>> first release of the 13.07 series and call a vote on it I would like
>>>>>>>>> to get your feedback on a couple of topics.
>>>>>>>>>
>>>>>>>>> Should we backport to it the recent switch to Java 7?
>>>>>>>>> Should we backport to it the recent update to Log4j2?
>>>>>>>>>
>>>>>>>>> The main reason I am asking this is that once we release the first
>>>>>>>>> release out of 13.07, for sure we will not backport the
>>>>>>>>> aforementioned upgrades (because they are not bugs); however the
>>>>>>>>> 13.07 releases will stay with us for at least 2 years and it would be
>>>>>>>>> nice to do the migration to these new technologies now.
>>>>>>>>>
>>>>>>>>> Thanks in advance,
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> -- 
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email: rwheeler@artifact-software.com
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>>
>

Re: Preparing for the 13.07.01 release

Posted by Adrian Crum <ad...@sandglass-software.com>.

And just to make sure there is no confusion, there is very little 
difference between the release branch and the release binary.

If I download the release binary and unzip it, then check out the latest 
release branch, I will have two copies of basically the same thing.

A release binary is not "more stable" than the branch, and the branch is 
not "less stable" than the release binary - as some have suggested.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 8/20/2014 4:38 PM, Jacopo Cappellato wrote:
> 13.07 is just a release branch for now, that we are stabilizing since July 2013 (when we branched it from trunk); no release yet was made... when we will release 13.07.01 that will be the first stable release.
>
> Jacopo
>
> On Aug 20, 2014, at 5:08 PM, Ron Wheeler <rw...@artifact-software.com> wrote:
>
>> I guess that I am still a little confused about the release policy.
>>
>> If 13.07 was frozen in July 2013 with all of the functionality defined, what was the date that it was "released" with the database fixed and the code "done" except for bug fixes (stable release?)?
>>
>> I am not sure that as a system admin, I would make the jump from someone putting a demo and me putting it into production.
>>
>> Was there a date that the development team said that it was now "recommended" for production use even though there were known bugs and a 13.07.01 release was scheduled in the future.
>> How can one know which 13.07 pre-release one has?
>>
>> Was this made available as a 13.07.00 or as a 13.07.01-SNAPSHOT?
>>
>> Ron
>>
>> On 19/08/2014 4:30 PM, Jacques Le Roux wrote:
>>>
>>> Le 19/08/2014 18:27, Ron Wheeler a écrit :
>>>> On 19/08/2014 10:59 AM, Adrian Crum wrote:
>>>>> Inline...
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>> On 8/19/2014 3:45 PM, Ron Wheeler wrote:
>>>>>> Java 6 is already 8 years old. Java 7 is 3 years old. Java 8 is pretty
>>>>>> new but worth considering if it is not a significant different from the
>>>>>> upgrade to Java 7.
>>>>>>
>>>>>> How much work was involved in the switch from 6 to 7.
>>>>>
>>>>>
>>>>> Unit tests fail in Java 7. They had to be modified.
>>>>>
>>>>>
>>>>>>
>>>>>> The difference between versions of Log4j would not seem to be a big
>>>>>> advantage or a big problem. I did this on one of our projects and it was
>>>>>> pretty painless. I also switched from properties to xml and that was a 1
>>>>>> hour project for my simple system.
>>>>>>
>>>>>>  From a marketing/project adoption point of view, a product based on an
>>>>>> 8 year old version of Java is a lot less attractive that one running on
>>>>>> the latest version.
>>>>>> It shows that the project team is on top of current technology and that
>>>>>> the project is active.
>>>>>> I don't think that people would care much about the version of log4j
>>>>>> when deciding whether to consider OfBiz.
>>>>>
>>>>>
>>>>> True, that shouldn't affect those considering OFBiz. But sys admins configure tools to analyze OFBiz logs, and the new format could break those tools.
>>>>> Keep in mind there may be hundreds of production deployments running on the R13 branch.
>>>>>
>>>> I thought that we are talking about the .01 release of 13.07.
>>>> Putting milestones or development trunks into production does entail some risk.
>>>> I am surprised that there are that many different system integrators or end-users that would put a development branch into production.
>>>> End-users are usually bound by corporate policies about using official releases.
>>>
>>> Remember that the R13.07 branch has been freezed since , er, 13/07. So those people don't take much risks. There is always a trade between official and efficient.
>>>
>>>>
>>>> I could imagine a few system integrators doing it for many clients but that means that only a few people would actually be affected as tool providers.
>>>>
>>>>
>>>>> Those sys admins could configure the new logger to produce logs that look like the old ones, but then that's extra work that they believe they shouldn't have to do on a "stable" release, and so forth and so on...
>>>> I was not aware that 13.07 had a "stable" release so far.
>>>
>>> Not officially, but you maybe noticed that the stable demo runs 13.07.
>>>
>>>> They knew that there where many risks and potential costs associated with using a development trunk in production.
>>>
>>> It's not a development trunk, only bug fixed are committed once a branch is freezed
>>>
>>>> Perhaps a change of this nature is at the edge of the normal risks but it is clearly within the realm of possibility.
>>>> Database changes, configuration setting changes, UI changes would be harder to deal with but are part of the risk of putting development into production.
>>>
>>> Nope, you can be reassured no new features, improvements will be normally committed to a freezed branch.
>>> That's why Jacopo asked about Java 7 and log4j2. Both are not risky at all, so I think it's possible to add  them.
>>>
>>>> On the good side, they already have 13.07 so they can continue to run on their fork until they have worked out their upgrade process.
>>>>
>>>> Can the configuration of the logs be documented as a cookbook or an alternate log4j.xml to reduce the effort if it affects so many?
>>>
>>> There is only that for now https://cwiki.apache.org/confluence/display/OFBTECH/Apache+OFBiz+Technical+Production+Setup+Guide#ApacheOFBizTechnicalProductionSetupGuide-DebugSettings
>>> But I guess it's enough for most of us
>>>
>>>>
>>>> One would hope that the sysadmin tools are pretty flexible and not tied to a specific logger or worse a specific log format.
>>>
>>> I hope so
>>>
>>> Jacques
>>>
>>>>
>>>> Ron
>>>>>
>>>>>
>>>>>>
>>>>>> I have not tried Java 8 so I can not comment on where problems can come
>>>>>> from.
>>>>>> Our move from 6 to 7 was pretty transparent but we did not have any code
>>>>>> developed with earlier versions of Java and did not try to retrofit new
>>>>>> Java 7 capabilities into existing code.
>>>>>
>>>>>
>>>>> There is no Java 7 specific code in the trunk. The recent changes were merely fixing compatibility issues with Java 6.
>>>>>
>>>>>
>>>>>>
>>>>>> You have already done this so you know the extent of the effort required.
>>>>>> I don't have to do the work so.....
>>>>>>
>>>>>> Ron
>>>>>>
>>>>>> On 19/08/2014 10:16 AM, Adrian Crum wrote:
>>>>>>> I don't have an opinion on this.
>>>>>>>
>>>>>>> The "rule" has been to keep backports restricted to bug fixes only,
>>>>>>> but we have a history of backporting various refactorings to make
>>>>>>> branch maintenance easier.
>>>>>>>
>>>>>>>  From my perspective, the two things cancel each other out, and I end
>>>>>>> up with no opinion.
>>>>>>>
>>>>>>> Adrian Crum
>>>>>>> Sandglass Software
>>>>>>> www.sandglass-software.com
>>>>>>>
>>>>>>> On 8/19/2014 2:34 PM, Jacopo Cappellato wrote:
>>>>>>>> Before I start the process of preparing the release files for the
>>>>>>>> first release of the 13.07 series and call a vote on it I would like
>>>>>>>> to get your feedback on a couple of topics.
>>>>>>>>
>>>>>>>> Should we backport to it the recent switch to Java 7?
>>>>>>>> Should we backport to it the recent update to Log4j2?
>>>>>>>>
>>>>>>>> The main reason I am asking this is that once we release the first
>>>>>>>> release out of 13.07, for sure we will not backport the
>>>>>>>> aforementioned upgrades (because they are not bugs); however the
>>>>>>>> 13.07 releases will stay with us for at least 2 years and it would be
>>>>>>>> nice to do the migration to these new technologies now.
>>>>>>>>
>>>>>>>> Thanks in advance,
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>

Re: Preparing for the 13.07.01 release

Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.

13.07 is just a release branch for now, that we are stabilizing since July 2013 (when we branched it from trunk); no release yet was made... when we will release 13.07.01 that will be the first stable release.

Jacopo

On Aug 20, 2014, at 5:08 PM, Ron Wheeler <rw...@artifact-software.com> wrote:

> I guess that I am still a little confused about the release policy.
> 
> If 13.07 was frozen in July 2013 with all of the functionality defined, what was the date that it was "released" with the database fixed and the code "done" except for bug fixes (stable release?)?
> 
> I am not sure that as a system admin, I would make the jump from someone putting a demo and me putting it into production.
> 
> Was there a date that the development team said that it was now "recommended" for production use even though there were known bugs and a 13.07.01 release was scheduled in the future.
> How can one know which 13.07 pre-release one has?
> 
> Was this made available as a 13.07.00 or as a 13.07.01-SNAPSHOT?
> 
> Ron
> 
> On 19/08/2014 4:30 PM, Jacques Le Roux wrote:
>> 
>> Le 19/08/2014 18:27, Ron Wheeler a écrit :
>>> On 19/08/2014 10:59 AM, Adrian Crum wrote:
>>>> Inline...
>>>> 
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>> 
>>>> On 8/19/2014 3:45 PM, Ron Wheeler wrote:
>>>>> Java 6 is already 8 years old. Java 7 is 3 years old. Java 8 is pretty
>>>>> new but worth considering if it is not a significant different from the
>>>>> upgrade to Java 7.
>>>>> 
>>>>> How much work was involved in the switch from 6 to 7.
>>>> 
>>>> 
>>>> Unit tests fail in Java 7. They had to be modified.
>>>> 
>>>> 
>>>>> 
>>>>> The difference between versions of Log4j would not seem to be a big
>>>>> advantage or a big problem. I did this on one of our projects and it was
>>>>> pretty painless. I also switched from properties to xml and that was a 1
>>>>> hour project for my simple system.
>>>>> 
>>>>> From a marketing/project adoption point of view, a product based on an
>>>>> 8 year old version of Java is a lot less attractive that one running on
>>>>> the latest version.
>>>>> It shows that the project team is on top of current technology and that
>>>>> the project is active.
>>>>> I don't think that people would care much about the version of log4j
>>>>> when deciding whether to consider OfBiz.
>>>> 
>>>> 
>>>> True, that shouldn't affect those considering OFBiz. But sys admins configure tools to analyze OFBiz logs, and the new format could break those tools.
>>>> Keep in mind there may be hundreds of production deployments running on the R13 branch.
>>>> 
>>> I thought that we are talking about the .01 release of 13.07.
>>> Putting milestones or development trunks into production does entail some risk.
>>> I am surprised that there are that many different system integrators or end-users that would put a development branch into production.
>>> End-users are usually bound by corporate policies about using official releases.
>> 
>> Remember that the R13.07 branch has been freezed since , er, 13/07. So those people don't take much risks. There is always a trade between official and efficient.
>> 
>>> 
>>> I could imagine a few system integrators doing it for many clients but that means that only a few people would actually be affected as tool providers.
>>> 
>>> 
>>>> Those sys admins could configure the new logger to produce logs that look like the old ones, but then that's extra work that they believe they shouldn't have to do on a "stable" release, and so forth and so on...
>>> I was not aware that 13.07 had a "stable" release so far.
>> 
>> Not officially, but you maybe noticed that the stable demo runs 13.07.
>> 
>>> They knew that there where many risks and potential costs associated with using a development trunk in production.
>> 
>> It's not a development trunk, only bug fixed are committed once a branch is freezed
>> 
>>> Perhaps a change of this nature is at the edge of the normal risks but it is clearly within the realm of possibility.
>>> Database changes, configuration setting changes, UI changes would be harder to deal with but are part of the risk of putting development into production.
>> 
>> Nope, you can be reassured no new features, improvements will be normally committed to a freezed branch.
>> That's why Jacopo asked about Java 7 and log4j2. Both are not risky at all, so I think it's possible to add  them.
>> 
>>> On the good side, they already have 13.07 so they can continue to run on their fork until they have worked out their upgrade process.
>>> 
>>> Can the configuration of the logs be documented as a cookbook or an alternate log4j.xml to reduce the effort if it affects so many?
>> 
>> There is only that for now https://cwiki.apache.org/confluence/display/OFBTECH/Apache+OFBiz+Technical+Production+Setup+Guide#ApacheOFBizTechnicalProductionSetupGuide-DebugSettings
>> But I guess it's enough for most of us
>> 
>>> 
>>> One would hope that the sysadmin tools are pretty flexible and not tied to a specific logger or worse a specific log format.
>> 
>> I hope so
>> 
>> Jacques
>> 
>>> 
>>> Ron
>>>> 
>>>> 
>>>>> 
>>>>> I have not tried Java 8 so I can not comment on where problems can come
>>>>> from.
>>>>> Our move from 6 to 7 was pretty transparent but we did not have any code
>>>>> developed with earlier versions of Java and did not try to retrofit new
>>>>> Java 7 capabilities into existing code.
>>>> 
>>>> 
>>>> There is no Java 7 specific code in the trunk. The recent changes were merely fixing compatibility issues with Java 6.
>>>> 
>>>> 
>>>>> 
>>>>> You have already done this so you know the extent of the effort required.
>>>>> I don't have to do the work so.....
>>>>> 
>>>>> Ron
>>>>> 
>>>>> On 19/08/2014 10:16 AM, Adrian Crum wrote:
>>>>>> I don't have an opinion on this.
>>>>>> 
>>>>>> The "rule" has been to keep backports restricted to bug fixes only,
>>>>>> but we have a history of backporting various refactorings to make
>>>>>> branch maintenance easier.
>>>>>> 
>>>>>> From my perspective, the two things cancel each other out, and I end
>>>>>> up with no opinion.
>>>>>> 
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>> 
>>>>>> On 8/19/2014 2:34 PM, Jacopo Cappellato wrote:
>>>>>>> Before I start the process of preparing the release files for the
>>>>>>> first release of the 13.07 series and call a vote on it I would like
>>>>>>> to get your feedback on a couple of topics.
>>>>>>> 
>>>>>>> Should we backport to it the recent switch to Java 7?
>>>>>>> Should we backport to it the recent update to Log4j2?
>>>>>>> 
>>>>>>> The main reason I am asking this is that once we release the first
>>>>>>> release out of 13.07, for sure we will not backport the
>>>>>>> aforementioned upgrades (because they are not bugs); however the
>>>>>>> 13.07 releases will stay with us for at least 2 years and it would be
>>>>>>> nice to do the migration to these new technologies now.
>>>>>>> 
>>>>>>> Thanks in advance,
>>>>>>> 
>>>>>>> Jacopo
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>

Re: Preparing for the 13.07.01 release

Posted by Ron Wheeler <rw...@artifact-software.com>.

I guess that I am still a little confused about the release policy.

If 13.07 was frozen in July 2013 with all of the functionality defined, 
what was the date that it was "released" with the database fixed and the 
code "done" except for bug fixes (stable release?)?

I am not sure that as a system admin, I would make the jump from someone 
putting a demo and me putting it into production.

Was there a date that the development team said that it was now 
"recommended" for production use even though there were known bugs and a 
13.07.01 release was scheduled in the future.
How can one know which 13.07 pre-release one has?

Was this made available as a 13.07.00 or as a 13.07.01-SNAPSHOT?

Ron

On 19/08/2014 4:30 PM, Jacques Le Roux wrote:
>
> Le 19/08/2014 18:27, Ron Wheeler a écrit :
>> On 19/08/2014 10:59 AM, Adrian Crum wrote:
>>> Inline...
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 8/19/2014 3:45 PM, Ron Wheeler wrote:
>>>> Java 6 is already 8 years old. Java 7 is 3 years old. Java 8 is pretty
>>>> new but worth considering if it is not a significant different from 
>>>> the
>>>> upgrade to Java 7.
>>>>
>>>> How much work was involved in the switch from 6 to 7.
>>>
>>>
>>> Unit tests fail in Java 7. They had to be modified.
>>>
>>>
>>>>
>>>> The difference between versions of Log4j would not seem to be a big
>>>> advantage or a big problem. I did this on one of our projects and 
>>>> it was
>>>> pretty painless. I also switched from properties to xml and that 
>>>> was a 1
>>>> hour project for my simple system.
>>>>
>>>>  From a marketing/project adoption point of view, a product based 
>>>> on an
>>>> 8 year old version of Java is a lot less attractive that one 
>>>> running on
>>>> the latest version.
>>>> It shows that the project team is on top of current technology and 
>>>> that
>>>> the project is active.
>>>> I don't think that people would care much about the version of log4j
>>>> when deciding whether to consider OfBiz.
>>>
>>>
>>> True, that shouldn't affect those considering OFBiz. But sys admins 
>>> configure tools to analyze OFBiz logs, and the new format could 
>>> break those tools.
>>> Keep in mind there may be hundreds of production deployments running 
>>> on the R13 branch.
>>>
>> I thought that we are talking about the .01 release of 13.07.
>> Putting milestones or development trunks into production does entail 
>> some risk.
>> I am surprised that there are that many different system integrators 
>> or end-users that would put a development branch into production.
>> End-users are usually bound by corporate policies about using 
>> official releases.
>
> Remember that the R13.07 branch has been freezed since , er, 13/07. So 
> those people don't take much risks. There is always a trade between 
> official and efficient.
>
>>
>> I could imagine a few system integrators doing it for many clients 
>> but that means that only a few people would actually be affected as 
>> tool providers.
>>
>>
>>> Those sys admins could configure the new logger to produce logs that 
>>> look like the old ones, but then that's extra work that they believe 
>>> they shouldn't have to do on a "stable" release, and so forth and so 
>>> on...
>> I was not aware that 13.07 had a "stable" release so far.
>
> Not officially, but you maybe noticed that the stable demo runs 13.07.
>
>> They knew that there where many risks and potential costs associated 
>> with using a development trunk in production.
>
> It's not a development trunk, only bug fixed are committed once a 
> branch is freezed
>
>> Perhaps a change of this nature is at the edge of the normal risks 
>> but it is clearly within the realm of possibility.
>> Database changes, configuration setting changes, UI changes would be 
>> harder to deal with but are part of the risk of putting development 
>> into production.
>
> Nope, you can be reassured no new features, improvements will be 
> normally committed to a freezed branch.
> That's why Jacopo asked about Java 7 and log4j2. Both are not risky at 
> all, so I think it's possible to add  them.
>
>> On the good side, they already have 13.07 so they can continue to run 
>> on their fork until they have worked out their upgrade process.
>>
>> Can the configuration of the logs be documented as a cookbook or an 
>> alternate log4j.xml to reduce the effort if it affects so many?
>
> There is only that for now 
> https://cwiki.apache.org/confluence/display/OFBTECH/Apache+OFBiz+Technical+Production+Setup+Guide#ApacheOFBizTechnicalProductionSetupGuide-DebugSettings
> But I guess it's enough for most of us
>
>>
>> One would hope that the sysadmin tools are pretty flexible and not 
>> tied to a specific logger or worse a specific log format.
>
> I hope so
>
> Jacques
>
>>
>> Ron
>>>
>>>
>>>>
>>>> I have not tried Java 8 so I can not comment on where problems can 
>>>> come
>>>> from.
>>>> Our move from 6 to 7 was pretty transparent but we did not have any 
>>>> code
>>>> developed with earlier versions of Java and did not try to retrofit 
>>>> new
>>>> Java 7 capabilities into existing code.
>>>
>>>
>>> There is no Java 7 specific code in the trunk. The recent changes 
>>> were merely fixing compatibility issues with Java 6.
>>>
>>>
>>>>
>>>> You have already done this so you know the extent of the effort 
>>>> required.
>>>> I don't have to do the work so.....
>>>>
>>>> Ron
>>>>
>>>> On 19/08/2014 10:16 AM, Adrian Crum wrote:
>>>>> I don't have an opinion on this.
>>>>>
>>>>> The "rule" has been to keep backports restricted to bug fixes only,
>>>>> but we have a history of backporting various refactorings to make
>>>>> branch maintenance easier.
>>>>>
>>>>> From my perspective, the two things cancel each other out, and I end
>>>>> up with no opinion.
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>> On 8/19/2014 2:34 PM, Jacopo Cappellato wrote:
>>>>>> Before I start the process of preparing the release files for the
>>>>>> first release of the 13.07 series and call a vote on it I would like
>>>>>> to get your feedback on a couple of topics.
>>>>>>
>>>>>> Should we backport to it the recent switch to Java 7?
>>>>>> Should we backport to it the recent update to Log4j2?
>>>>>>
>>>>>> The main reason I am asking this is that once we release the first
>>>>>> release out of 13.07, for sure we will not backport the
>>>>>> aforementioned upgrades (because they are not bugs); however the
>>>>>> 13.07 releases will stay with us for at least 2 years and it 
>>>>>> would be
>>>>>> nice to do the migration to these new technologies now.
>>>>>>
>>>>>> Thanks in advance,
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Preparing for the 13.07.01 release

Posted by Ron Wheeler <rw...@artifact-software.com>.

Good points.

As a new person, I am still learning about the community and how it works.

Ron

On 19/08/2014 4:30 PM, Jacques Le Roux wrote:
>
> Le 19/08/2014 18:27, Ron Wheeler a écrit :
>> On 19/08/2014 10:59 AM, Adrian Crum wrote:
>>> Inline...
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 8/19/2014 3:45 PM, Ron Wheeler wrote:
>>>> Java 6 is already 8 years old. Java 7 is 3 years old. Java 8 is pretty
>>>> new but worth considering if it is not a significant different from 
>>>> the
>>>> upgrade to Java 7.
>>>>
>>>> How much work was involved in the switch from 6 to 7.
>>>
>>>
>>> Unit tests fail in Java 7. They had to be modified.
>>>
>>>
>>>>
>>>> The difference between versions of Log4j would not seem to be a big
>>>> advantage or a big problem. I did this on one of our projects and 
>>>> it was
>>>> pretty painless. I also switched from properties to xml and that 
>>>> was a 1
>>>> hour project for my simple system.
>>>>
>>>>  From a marketing/project adoption point of view, a product based 
>>>> on an
>>>> 8 year old version of Java is a lot less attractive that one 
>>>> running on
>>>> the latest version.
>>>> It shows that the project team is on top of current technology and 
>>>> that
>>>> the project is active.
>>>> I don't think that people would care much about the version of log4j
>>>> when deciding whether to consider OfBiz.
>>>
>>>
>>> True, that shouldn't affect those considering OFBiz. But sys admins 
>>> configure tools to analyze OFBiz logs, and the new format could 
>>> break those tools.
>>> Keep in mind there may be hundreds of production deployments running 
>>> on the R13 branch.
>>>
>> I thought that we are talking about the .01 release of 13.07.
>> Putting milestones or development trunks into production does entail 
>> some risk.
>> I am surprised that there are that many different system integrators 
>> or end-users that would put a development branch into production.
>> End-users are usually bound by corporate policies about using 
>> official releases.
>
> Remember that the R13.07 branch has been freezed since , er, 13/07. So 
> those people don't take much risks. There is always a trade between 
> official and efficient.
>
>>
>> I could imagine a few system integrators doing it for many clients 
>> but that means that only a few people would actually be affected as 
>> tool providers.
>>
>>
>>> Those sys admins could configure the new logger to produce logs that 
>>> look like the old ones, but then that's extra work that they believe 
>>> they shouldn't have to do on a "stable" release, and so forth and so 
>>> on...
>> I was not aware that 13.07 had a "stable" release so far.
>
> Not officially, but you maybe noticed that the stable demo runs 13.07.
>
>> They knew that there where many risks and potential costs associated 
>> with using a development trunk in production.
>
> It's not a development trunk, only bug fixed are committed once a 
> branch is freezed
>
>> Perhaps a change of this nature is at the edge of the normal risks 
>> but it is clearly within the realm of possibility.
>> Database changes, configuration setting changes, UI changes would be 
>> harder to deal with but are part of the risk of putting development 
>> into production.
>
> Nope, you can be reassured no new features, improvements will be 
> normally committed to a freezed branch.
> That's why Jacopo asked about Java 7 and log4j2. Both are not risky at 
> all, so I think it's possible to add  them.
>
>> On the good side, they already have 13.07 so they can continue to run 
>> on their fork until they have worked out their upgrade process.
>>
>> Can the configuration of the logs be documented as a cookbook or an 
>> alternate log4j.xml to reduce the effort if it affects so many?
>
> There is only that for now 
> https://cwiki.apache.org/confluence/display/OFBTECH/Apache+OFBiz+Technical+Production+Setup+Guide#ApacheOFBizTechnicalProductionSetupGuide-DebugSettings
> But I guess it's enough for most of us
>
>>
>> One would hope that the sysadmin tools are pretty flexible and not 
>> tied to a specific logger or worse a specific log format.
>
> I hope so
>
> Jacques
>
>>
>> Ron
>>>
>>>
>>>>
>>>> I have not tried Java 8 so I can not comment on where problems can 
>>>> come
>>>> from.
>>>> Our move from 6 to 7 was pretty transparent but we did not have any 
>>>> code
>>>> developed with earlier versions of Java and did not try to retrofit 
>>>> new
>>>> Java 7 capabilities into existing code.
>>>
>>>
>>> There is no Java 7 specific code in the trunk. The recent changes 
>>> were merely fixing compatibility issues with Java 6.
>>>
>>>
>>>>
>>>> You have already done this so you know the extent of the effort 
>>>> required.
>>>> I don't have to do the work so.....
>>>>
>>>> Ron
>>>>
>>>> On 19/08/2014 10:16 AM, Adrian Crum wrote:
>>>>> I don't have an opinion on this.
>>>>>
>>>>> The "rule" has been to keep backports restricted to bug fixes only,
>>>>> but we have a history of backporting various refactorings to make
>>>>> branch maintenance easier.
>>>>>
>>>>> From my perspective, the two things cancel each other out, and I end
>>>>> up with no opinion.
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>> On 8/19/2014 2:34 PM, Jacopo Cappellato wrote:
>>>>>> Before I start the process of preparing the release files for the
>>>>>> first release of the 13.07 series and call a vote on it I would like
>>>>>> to get your feedback on a couple of topics.
>>>>>>
>>>>>> Should we backport to it the recent switch to Java 7?
>>>>>> Should we backport to it the recent update to Log4j2?
>>>>>>
>>>>>> The main reason I am asking this is that once we release the first
>>>>>> release out of 13.07, for sure we will not backport the
>>>>>> aforementioned upgrades (because they are not bugs); however the
>>>>>> 13.07 releases will stay with us for at least 2 years and it 
>>>>>> would be
>>>>>> nice to do the migration to these new technologies now.
>>>>>>
>>>>>> Thanks in advance,
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Preparing for the 13.07.01 release

Posted by Jacques Le Roux <ja...@les7arts.com>.

Le 19/08/2014 18:27, Ron Wheeler a écrit :
> On 19/08/2014 10:59 AM, Adrian Crum wrote:
>> Inline...
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 8/19/2014 3:45 PM, Ron Wheeler wrote:
>>> Java 6 is already 8 years old. Java 7 is 3 years old. Java 8 is pretty
>>> new but worth considering if it is not a significant different from the
>>> upgrade to Java 7.
>>>
>>> How much work was involved in the switch from 6 to 7.
>>
>>
>> Unit tests fail in Java 7. They had to be modified.
>>
>>
>>>
>>> The difference between versions of Log4j would not seem to be a big
>>> advantage or a big problem. I did this on one of our projects and it was
>>> pretty painless. I also switched from properties to xml and that was a 1
>>> hour project for my simple system.
>>>
>>>  From a marketing/project adoption point of view, a product based on an
>>> 8 year old version of Java is a lot less attractive that one running on
>>> the latest version.
>>> It shows that the project team is on top of current technology and that
>>> the project is active.
>>> I don't think that people would care much about the version of log4j
>>> when deciding whether to consider OfBiz.
>>
>>
>> True, that shouldn't affect those considering OFBiz. But sys admins configure tools to analyze OFBiz logs, and the new format could break those tools.
>> Keep in mind there may be hundreds of production deployments running on the R13 branch.
>>
> I thought that we are talking about the .01 release of 13.07.
> Putting milestones or development trunks into production does entail some risk.
> I am surprised that there are that many different system integrators or end-users that would put a development branch into production.
> End-users are usually bound by corporate policies about using official releases.

Remember that the R13.07 branch has been freezed since , er, 13/07. So those people don't take much risks. There is always a trade between official 
and efficient.

>
> I could imagine a few system integrators doing it for many clients but that means that only a few people would actually be affected as tool providers.
>
>
>> Those sys admins could configure the new logger to produce logs that look like the old ones, but then that's extra work that they believe they 
>> shouldn't have to do on a "stable" release, and so forth and so on...
> I was not aware that 13.07 had a "stable" release so far.

Not officially, but you maybe noticed that the stable demo runs 13.07.

> They knew that there where many risks and potential costs associated with using a development trunk in production.

It's not a development trunk, only bug fixed are committed once a branch is freezed

> Perhaps a change of this nature is at the edge of the normal risks but it is clearly within the realm of possibility.
> Database changes, configuration setting changes, UI changes would be harder to deal with but are part of the risk of putting development into 
> production.

Nope, you can be reassured no new features, improvements will be normally committed to a freezed branch.
That's why Jacopo asked about Java 7 and log4j2. Both are not risky at all, so I think it's possible to add  them.

> On the good side, they already have 13.07 so they can continue to run on their fork until they have worked out their upgrade process.
>
> Can the configuration of the logs be documented as a cookbook or an alternate log4j.xml to reduce the effort if it affects so many?

There is only that for now 
https://cwiki.apache.org/confluence/display/OFBTECH/Apache+OFBiz+Technical+Production+Setup+Guide#ApacheOFBizTechnicalProductionSetupGuide-DebugSettings
But I guess it's enough for most of us

>
> One would hope that the sysadmin tools are pretty flexible and not tied to a specific logger or worse a specific log format.

I hope so

Jacques

>
> Ron
>>
>>
>>>
>>> I have not tried Java 8 so I can not comment on where problems can come
>>> from.
>>> Our move from 6 to 7 was pretty transparent but we did not have any code
>>> developed with earlier versions of Java and did not try to retrofit new
>>> Java 7 capabilities into existing code.
>>
>>
>> There is no Java 7 specific code in the trunk. The recent changes were merely fixing compatibility issues with Java 6.
>>
>>
>>>
>>> You have already done this so you know the extent of the effort required.
>>> I don't have to do the work so.....
>>>
>>> Ron
>>>
>>> On 19/08/2014 10:16 AM, Adrian Crum wrote:
>>>> I don't have an opinion on this.
>>>>
>>>> The "rule" has been to keep backports restricted to bug fixes only,
>>>> but we have a history of backporting various refactorings to make
>>>> branch maintenance easier.
>>>>
>>>> From my perspective, the two things cancel each other out, and I end
>>>> up with no opinion.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 8/19/2014 2:34 PM, Jacopo Cappellato wrote:
>>>>> Before I start the process of preparing the release files for the
>>>>> first release of the 13.07 series and call a vote on it I would like
>>>>> to get your feedback on a couple of topics.
>>>>>
>>>>> Should we backport to it the recent switch to Java 7?
>>>>> Should we backport to it the recent update to Log4j2?
>>>>>
>>>>> The main reason I am asking this is that once we release the first
>>>>> release out of 13.07, for sure we will not backport the
>>>>> aforementioned upgrades (because they are not bugs); however the
>>>>> 13.07 releases will stay with us for at least 2 years and it would be
>>>>> nice to do the migration to these new technologies now.
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> Jacopo
>>>>>
>>>>
>>>
>>>
>>
>
>

Re: Preparing for the 13.07.01 release

Posted by Pierre Smits <pi...@gmail.com>.

As far as we can tell we don't know how many do run OFBiz from the
unreleased 13.x branch, as we don't have anhy download metrics.

If the release manager of r13.07.01 (Jacopo) feels confident that the risk
of incorporating Java 7 and Log4J2 is minimal, then I would say go ahead.
>From a marketing point of view it would include something relatively new as
the freeze is already a year old.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

Re: Preparing for the 13.07.01 release

Posted by Ron Wheeler <rw...@artifact-software.com>.

On 19/08/2014 10:59 AM, Adrian Crum wrote:
> Inline...
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 8/19/2014 3:45 PM, Ron Wheeler wrote:
>> Java 6 is already 8 years old. Java 7 is 3 years old. Java 8 is pretty
>> new but worth considering if it is not a significant different from the
>> upgrade to Java 7.
>>
>> How much work was involved in the switch from 6 to 7.
>
>
> Unit tests fail in Java 7. They had to be modified.
>
>
>>
>> The difference between versions of Log4j would not seem to be a big
>> advantage or a big problem. I did this on one of our projects and it was
>> pretty painless. I also switched from properties to xml and that was a 1
>> hour project for my simple system.
>>
>>  From a marketing/project adoption point of view, a product based on an
>> 8 year old version of Java is a lot less attractive that one running on
>> the latest version.
>> It shows that the project team is on top of current technology and that
>> the project is active.
>> I don't think that people would care much about the version of log4j
>> when deciding whether to consider OfBiz.
>
>
> True, that shouldn't affect those considering OFBiz. But sys admins 
> configure tools to analyze OFBiz logs, and the new format could break 
> those tools.
> Keep in mind there may be hundreds of production deployments running 
> on the R13 branch.
>
I thought that we are talking about the .01 release of 13.07.
Putting milestones or development trunks into production does entail 
some risk.
I am surprised that there are that many different system integrators or 
end-users that would put a development branch into production.
End-users are usually bound by corporate policies about using official 
releases.

I could imagine a few system integrators doing it for many clients but 
that means that only a few people would actually be affected as tool 
providers.


> Those sys admins could configure the new logger to produce logs that 
> look like the old ones, but then that's extra work that they believe 
> they shouldn't have to do on a "stable" release, and so forth and so 
> on...
I was not aware that 13.07 had a "stable" release so far.
They knew that there where many risks and potential costs associated 
with using a development trunk in production.
Perhaps a change of this nature is at the edge of the normal risks but 
it is clearly within the realm of possibility.
Database changes, configuration setting changes, UI changes would be 
harder to deal with but are part of the risk of putting development into 
production.
On the good side, they already have 13.07 so they can continue to run on 
their fork until they have worked out their upgrade process.

Can the configuration of the logs be documented as a cookbook or an 
alternate log4j.xml to reduce the effort if it affects so many?

One would hope that the sysadmin tools are pretty flexible and not tied 
to a specific logger or worse a specific log format.

Ron
>
>
>>
>> I have not tried Java 8 so I can not comment on where problems can come
>> from.
>> Our move from 6 to 7 was pretty transparent but we did not have any code
>> developed with earlier versions of Java and did not try to retrofit new
>> Java 7 capabilities into existing code.
>
>
> There is no Java 7 specific code in the trunk. The recent changes were 
> merely fixing compatibility issues with Java 6.
>
>
>>
>> You have already done this so you know the extent of the effort 
>> required.
>> I don't have to do the work so.....
>>
>> Ron
>>
>> On 19/08/2014 10:16 AM, Adrian Crum wrote:
>>> I don't have an opinion on this.
>>>
>>> The "rule" has been to keep backports restricted to bug fixes only,
>>> but we have a history of backporting various refactorings to make
>>> branch maintenance easier.
>>>
>>> From my perspective, the two things cancel each other out, and I end
>>> up with no opinion.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 8/19/2014 2:34 PM, Jacopo Cappellato wrote:
>>>> Before I start the process of preparing the release files for the
>>>> first release of the 13.07 series and call a vote on it I would like
>>>> to get your feedback on a couple of topics.
>>>>
>>>> Should we backport to it the recent switch to Java 7?
>>>> Should we backport to it the recent update to Log4j2?
>>>>
>>>> The main reason I am asking this is that once we release the first
>>>> release out of 13.07, for sure we will not backport the
>>>> aforementioned upgrades (because they are not bugs); however the
>>>> 13.07 releases will stay with us for at least 2 years and it would be
>>>> nice to do the migration to these new technologies now.
>>>>
>>>> Thanks in advance,
>>>>
>>>> Jacopo
>>>>
>>>
>>
>>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Preparing for the 13.07.01 release

Posted by Adrian Crum <ad...@sandglass-software.com>.

Inline...

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 8/19/2014 3:45 PM, Ron Wheeler wrote:
> Java 6 is already 8 years old. Java 7 is 3 years old. Java 8 is pretty
> new but worth considering if it is not a significant different from the
> upgrade to Java 7.
>
> How much work was involved in the switch from 6 to 7.


Unit tests fail in Java 7. They had to be modified.


>
> The difference between versions of Log4j would not seem to be a big
> advantage or a big problem. I did this on one of our projects and it was
> pretty painless. I also switched from properties to xml and that was a 1
> hour project for my simple system.
>
>  From a marketing/project adoption point of view, a product based on an
> 8 year old version of Java is a lot less attractive that one running on
> the latest version.
> It shows that the project team is on top of current technology and that
> the project is active.
> I don't think that people would care much about the version of log4j
> when deciding whether to consider OfBiz.


True, that shouldn't affect those considering OFBiz. But sys admins 
configure tools to analyze OFBiz logs, and the new format could break 
those tools. Keep in mind there may be hundreds of production 
deployments running on the R13 branch.

Those sys admins could configure the new logger to produce logs that 
look like the old ones, but then that's extra work that they believe 
they shouldn't have to do on a "stable" release, and so forth and so on...


>
> I have not tried Java 8 so I can not comment on where problems can come
> from.
> Our move from 6 to 7 was pretty transparent but we did not have any code
> developed with earlier versions of Java and did not try to retrofit new
> Java 7 capabilities into existing code.


There is no Java 7 specific code in the trunk. The recent changes were 
merely fixing compatibility issues with Java 6.


>
> You have already done this so you know the extent of the effort required.
> I don't have to do the work so.....
>
> Ron
>
> On 19/08/2014 10:16 AM, Adrian Crum wrote:
>> I don't have an opinion on this.
>>
>> The "rule" has been to keep backports restricted to bug fixes only,
>> but we have a history of backporting various refactorings to make
>> branch maintenance easier.
>>
>> From my perspective, the two things cancel each other out, and I end
>> up with no opinion.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 8/19/2014 2:34 PM, Jacopo Cappellato wrote:
>>> Before I start the process of preparing the release files for the
>>> first release of the 13.07 series and call a vote on it I would like
>>> to get your feedback on a couple of topics.
>>>
>>> Should we backport to it the recent switch to Java 7?
>>> Should we backport to it the recent update to Log4j2?
>>>
>>> The main reason I am asking this is that once we release the first
>>> release out of 13.07, for sure we will not backport the
>>> aforementioned upgrades (because they are not bugs); however the
>>> 13.07 releases will stay with us for at least 2 years and it would be
>>> nice to do the migration to these new technologies now.
>>>
>>> Thanks in advance,
>>>
>>> Jacopo
>>>
>>
>
>

Re: Preparing for the 13.07.01 release

Posted by Ron Wheeler <rw...@artifact-software.com>.

Java 6 is already 8 years old. Java 7 is 3 years old. Java 8 is pretty 
new but worth considering if it is not a significant different from the 
upgrade to Java 7.

How much work was involved in the switch from 6 to 7.

The difference between versions of Log4j would not seem to be a big 
advantage or a big problem. I did this on one of our projects and it was 
pretty painless. I also switched from properties to xml and that was a 1 
hour project for my simple system.

 From a marketing/project adoption point of view, a product based on an 
8 year old version of Java is a lot less attractive that one running on 
the latest version.
It shows that the project team is on top of current technology and that 
the project is active.
I don't think that people would care much about the version of log4j 
when deciding whether to consider OfBiz.

I have not tried Java 8 so I can not comment on where problems can come 
from.
Our move from 6 to 7 was pretty transparent but we did not have any code 
developed with earlier versions of Java and did not try to retrofit new 
Java 7 capabilities into existing code.

You have already done this so you know the extent of the effort required.
I don't have to do the work so.....

Ron

On 19/08/2014 10:16 AM, Adrian Crum wrote:
> I don't have an opinion on this.
>
> The "rule" has been to keep backports restricted to bug fixes only, 
> but we have a history of backporting various refactorings to make 
> branch maintenance easier.
>
> From my perspective, the two things cancel each other out, and I end 
> up with no opinion.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 8/19/2014 2:34 PM, Jacopo Cappellato wrote:
>> Before I start the process of preparing the release files for the 
>> first release of the 13.07 series and call a vote on it I would like 
>> to get your feedback on a couple of topics.
>>
>> Should we backport to it the recent switch to Java 7?
>> Should we backport to it the recent update to Log4j2?
>>
>> The main reason I am asking this is that once we release the first 
>> release out of 13.07, for sure we will not backport the 
>> aforementioned upgrades (because they are not bugs); however the 
>> 13.07 releases will stay with us for at least 2 years and it would be 
>> nice to do the migration to these new technologies now.
>>
>> Thanks in advance,
>>
>> Jacopo
>>
>

-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Preparing for the 13.07.01 release

Posted by Jacques Le Roux <ja...@les7arts.com>.

I'm using trunk for a development and there are no issues with Java7, so IMO we can backport yes
We could wait a bit (few weeks?) for log4j2, there is no hurry to release I guess?

Jacques

Le 19/08/2014 16:16, Adrian Crum a écrit :
> I don't have an opinion on this.
>
> The "rule" has been to keep backports restricted to bug fixes only, but we have a history of backporting various refactorings to make branch 
> maintenance easier.
>
> From my perspective, the two things cancel each other out, and I end up with no opinion.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 8/19/2014 2:34 PM, Jacopo Cappellato wrote:
>> Before I start the process of preparing the release files for the first release of the 13.07 series and call a vote on it I would like to get your 
>> feedback on a couple of topics.
>>
>> Should we backport to it the recent switch to Java 7?
>> Should we backport to it the recent update to Log4j2?
>>
>> The main reason I am asking this is that once we release the first release out of 13.07, for sure we will not backport the aforementioned upgrades 
>> (because they are not bugs); however the 13.07 releases will stay with us for at least 2 years and it would be nice to do the migration to these 
>> new technologies now.
>>
>> Thanks in advance,
>>
>> Jacopo
>>
>

Re: Preparing for the 13.07.01 release

Posted by Adrian Crum <ad...@sandglass-software.com>.

I don't have an opinion on this.

The "rule" has been to keep backports restricted to bug fixes only, but 
we have a history of backporting various refactorings to make branch 
maintenance easier.

 From my perspective, the two things cancel each other out, and I end up 
with no opinion.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 8/19/2014 2:34 PM, Jacopo Cappellato wrote:
> Before I start the process of preparing the release files for the first release of the 13.07 series and call a vote on it I would like to get your feedback on a couple of topics.
>
> Should we backport to it the recent switch to Java 7?
> Should we backport to it the recent update to Log4j2?
>
> The main reason I am asking this is that once we release the first release out of 13.07, for sure we will not backport the aforementioned upgrades (because they are not bugs); however the 13.07 releases will stay with us for at least 2 years and it would be nice to do the migration to these new technologies now.
>
> Thanks in advance,
>
> Jacopo
>

Re: Preparing for the 13.07.01 release

Posted by Anil Patel <an...@hotwaxmedia.com>.

Back porting of Log4j2 is good idea. To understand performance gains, Has anybody in community performed load test on 13.07 release branch? If so, it will be nice to get some statistics.

Regards
Anil Patel




On Aug 20, 2014, at 12:34 PM, Jacopo Cappellato <ja...@hotwaxmedia.com> wrote:

> Thanks to all of you for your valuable feedback.
> Based on all your comments I would like to:
> 1) do NOT switch 13.07 to Java 7: in fact 13.07 already works with both Java 6 and Java 7; but the switch would *require* Java 7 and this is probably not a good idea since the release branch is already one year old
> 2) do the upgrade to Log4j2: as mentioned by Adrian, this could cause some issues to sys admins but the benefit of running a faster and more reliable logging framework seems a valid
> 3) wait a few weeks before preparing for the 13.07.01 release (i.e. sometime in September) in order to give time to test and fine tune the Log4j2 configuration
> 
> Regards,
> 
> Jacopo
> 
> On Aug 20, 2014, at 8:48 AM, Jacques Le Roux <ja...@les7arts.com> wrote:
> 
>> Le 19/08/2014 23:36, Christian Geisert a écrit :
>>> Am 19.08.2014 15:34, schrieb Jacopo Cappellato:
>>>> Before I start the process of preparing the release files for the first release of the 13.07 series and call a vote on it I would like to get your feedback on a couple of topics.
>>>> 
>>>> Should we backport to it the recent switch to Java 7?
>>> What does this mean exactly?
>>> Should it run with Java 7 (including passing all tests)? Yes, of course
>>> ... actually is does, I just checked.
>>> 
>>> Should Java 7 be the minimum requirement to run it? I'm not sure on this
>>> one ... about which commit are you talking?
>> 
>> If we copy all from trunk, there we forced to use Java 7 (in macros.xml)
>> 
>>> 
>>>> Should we backport to it the recent update to Log4j2?
>>> I haven't followed this changed closely but it sounds good and "No more
>>> missing log entries due to logger overflows" sounds actually like a
>>> bugfix to me ;-)
>>> 
>>> +1 for this change
>> 
>> Hè Christian, you are quite right! :)
>> 
>> Jacques
>> 
>>>> The main reason I am asking this is that once we release the first release out of 13.07, for sure we will not backport the aforementioned upgrades (because they are not bugs); however the 13.07 releases will stay with us for at least 2 years and it would be nice to do the migration to these new technologies now.
>>> 
>>> Christian
>>> 
>>> 
>

Re: Preparing for the 13.07.01 release

Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.

Thanks to all of you for your valuable feedback.
Based on all your comments I would like to:
1) do NOT switch 13.07 to Java 7: in fact 13.07 already works with both Java 6 and Java 7; but the switch would *require* Java 7 and this is probably not a good idea since the release branch is already one year old
2) do the upgrade to Log4j2: as mentioned by Adrian, this could cause some issues to sys admins but the benefit of running a faster and more reliable logging framework seems a valid
3) wait a few weeks before preparing for the 13.07.01 release (i.e. sometime in September) in order to give time to test and fine tune the Log4j2 configuration

Regards,

Jacopo

On Aug 20, 2014, at 8:48 AM, Jacques Le Roux <ja...@les7arts.com> wrote:

> Le 19/08/2014 23:36, Christian Geisert a écrit :
>> Am 19.08.2014 15:34, schrieb Jacopo Cappellato:
>>> Before I start the process of preparing the release files for the first release of the 13.07 series and call a vote on it I would like to get your feedback on a couple of topics.
>>> 
>>> Should we backport to it the recent switch to Java 7?
>> What does this mean exactly?
>> Should it run with Java 7 (including passing all tests)? Yes, of course
>> ... actually is does, I just checked.
>> 
>> Should Java 7 be the minimum requirement to run it? I'm not sure on this
>> one ... about which commit are you talking?
> 
> If we copy all from trunk, there we forced to use Java 7 (in macros.xml)
> 
>> 
>>> Should we backport to it the recent update to Log4j2?
>> I haven't followed this changed closely but it sounds good and "No more
>> missing log entries due to logger overflows" sounds actually like a
>> bugfix to me ;-)
>> 
>> +1 for this change
> 
> Hè Christian, you are quite right! :)
> 
> Jacques
> 
>>> The main reason I am asking this is that once we release the first release out of 13.07, for sure we will not backport the aforementioned upgrades (because they are not bugs); however the 13.07 releases will stay with us for at least 2 years and it would be nice to do the migration to these new technologies now.
>> 
>> Christian
>> 
>>

Re: Preparing for the 13.07.01 release

Posted by Jacques Le Roux <ja...@les7arts.com>.

Le 19/08/2014 23:36, Christian Geisert a écrit :
> Am 19.08.2014 15:34, schrieb Jacopo Cappellato:
>> Before I start the process of preparing the release files for the first release of the 13.07 series and call a vote on it I would like to get your feedback on a couple of topics.
>>
>> Should we backport to it the recent switch to Java 7?
> What does this mean exactly?
> Should it run with Java 7 (including passing all tests)? Yes, of course
> ... actually is does, I just checked.
>
> Should Java 7 be the minimum requirement to run it? I'm not sure on this
> one ... about which commit are you talking?

If we copy all from trunk, there we forced to use Java 7 (in macros.xml)

>
>> Should we backport to it the recent update to Log4j2?
> I haven't followed this changed closely but it sounds good and "No more
> missing log entries due to logger overflows" sounds actually like a
> bugfix to me ;-)
>
> +1 for this change

Hè Christian, you are quite right! :)

Jacques

>> The main reason I am asking this is that once we release the first release out of 13.07, for sure we will not backport the aforementioned upgrades (because they are not bugs); however the 13.07 releases will stay with us for at least 2 years and it would be nice to do the migration to these new technologies now.
>
> Christian
>
>

Re: Preparing for the 13.07.01 release

Posted by Christian Geisert <ch...@isu-gmbh.de>.

Am 19.08.2014 15:34, schrieb Jacopo Cappellato:
> Before I start the process of preparing the release files for the first release of the 13.07 series and call a vote on it I would like to get your feedback on a couple of topics.
> 
> Should we backport to it the recent switch to Java 7?

What does this mean exactly?
Should it run with Java 7 (including passing all tests)? Yes, of course
... actually is does, I just checked.

Should Java 7 be the minimum requirement to run it? I'm not sure on this
one ... about which commit are you talking?

> Should we backport to it the recent update to Log4j2?

I haven't followed this changed closely but it sounds good and "No more
missing log entries due to logger overflows" sounds actually like a
bugfix to me ;-)

+1 for this change

> The main reason I am asking this is that once we release the first release out of 13.07, for sure we will not backport the aforementioned upgrades (because they are not bugs); however the 13.07 releases will stay with us for at least 2 years and it would be nice to do the migration to these new technologies now.


Christian

Re: Preparing for the 13.07.01 release

Posted by Ashish Vijaywargiya <vi...@gmail.com>.

Both the additions are good. I must say we can go ahead and provide support
of Java 7 and Log4j2 in Release 13.07.

>> True, that shouldn't affect those considering OFBiz. But sys admins
configure tools to analyze OFBiz logs, and the new format could break those
tools. Keep in mind there may be >> hundreds of production deployments
running on the R13 branch.

I agree that there may be some issues at Sys Admin end due to new log
format. But most of the sys admin guys(More than 10) with whom I met were
smart enough and they can do necessary changes within a short duration of
time. And still if they are having any major issues they can share their
concerns on the mailing list and we can help them.

--
Kind Regards,
Ashish Vijaywargiya

On Tue, Aug 19, 2014 at 7:04 PM, Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> wrote:

> Before I start the process of preparing the release files for the first
> release of the 13.07 series and call a vote on it I would like to get your
> feedback on a couple of topics.
>
> Should we backport to it the recent switch to Java 7?
> Should we backport to it the recent update to Log4j2?
>
> The main reason I am asking this is that once we release the first release
> out of 13.07, for sure we will not backport the aforementioned upgrades
> (because they are not bugs); however the 13.07 releases will stay with us
> for at least 2 years and it would be nice to do the migration to these new
> technologies now.
>
> Thanks in advance,
>
> Jacopo