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: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102