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
<[email protected]> 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: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
