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
