On 23/10/2014 3:32 PM, Jacques Le Roux wrote:
Le 23/10/2014 19:52, Ron Wheeler a écrit :
I don't think that I was implying that in the point that I was trying
to make.
It is my theory that the way that this project deals with the
releases and the trunk is directly related to the fact that most of
the people involved have customers for whom they fork the OFBiz
system and deliver a forked version to which they apply patches and
improvements when they get applied to the trunk rather than using the
official release as a base for their deliverables.
Actually I believe more and more OFBiz service providers rely on one
of the release branches, less and less the trunk HEAD.
One would think that this would generate a lot of support for backporting.
But yes, there are also maybe few OFBiz service providers who start
with a static packaged releases for a client custom project.
Thought it's far easier to svn update a release branch where bug fixes
are "routinely" backported by committers than to muck around with
patches to apply on a static packaged releases or anything else static
(static meaning here with no connection with the OFBiz svn repo).
This is actually even true for anybody working from OFBiz.
Jacques
This may appear to work but I think that it hurts the project and
probably has a negative effect on the overall profitability of the
OFBiz market served by these companies.
Ron
On 23/10/2014 12:33 PM, Pierre @GMail wrote:
The others participating in this project ( with and without
customers are of no importance?
Regards,
Pierre
Sent from my iPhone
On 23 okt. 2014, at 18:04, Ron Wheeler
<rwhee...@artifact-software.com> wrote:
On 23/10/2014 11:33 AM, Jacques Le Roux wrote:
Le 23/10/2014 17:11, Ron Wheeler a écrit :
On 23/10/2014 10:39 AM, Jacques Le Roux wrote:
Le 23/10/2014 15:01, Jacopo Cappellato a écrit :
On Oct 23, 2014, at 2:07 PM, Jacques Le Roux
<jacques.le.r...@les7arts.com> wrote:
I agree about the idea, but this applies only to releases or
checked out code. Because there are no ways for users to
enable/disable a component in demos, moreover demos are shared.
Could you please explain the above sentence? I don't understand
the meaning of it.
Your idea of disabling some specialpurpose component can't be
applied in R13.07 demo until we decide which component should be
disabled in trunk.
In the meantime we should keep the current state (ie all
specialpurpose components present in trunk should be available
in R13.07 demo)
If they are in the demo they should be in the release.
Actually the specialpurpose components are in the R13.07 demos
because they can be there. But they are not maintained in the
R13.07 branch (but ecommerce) only in trunk.
As you can guess, I am troubled about the relation between
releases and the trunk and demos in OFBiz.
Would you prefer to not have the specialpurpose components in
R13.07 demo?
It is a bit odd and certainly goes against most product release
strategies wherein the current release is the recommended
download and carries whatever warranty that the project offers in
terms of testing and rapidity of bug fixes and the trunk is
usually called something that includes"nightly build" and
"unstable" in the name and comes with no warranty and a warning
about using it at your own risk.
Demos should be of the latest release and should be stable and
have a fixed functionality that can be documented in the wiki and
marketing pages.
They are, just that they use the branch instead of the packaged
releases. For R13.07 (current stable) there is an exception,
because I thought it was better to have the specialpurpose
components available. This is what Jacopo contests
It could be maintained by the documentation team once it is set
up since it should not require any technical skills to keep
working and fed with demo data.
If the developers need a test site based on the nightly build,
they should be free to set up as many combinations of
configurations as they require and can support to be sure that
the trunk still works but this should not be the public demo or
even be called a "demo".
It's also, there are no official mention of the trunk demo, it's
only a developers thing.
Of course, this only works if a release is actually a Release and
the team stands behind it and uses it when establishing new
customers.
We have no customers, only users
The PMC members have the customers to whom I was referring.
Jacques
Does anyone have an opinion about the gap between 13.07.01 and
what the main SI companies are getting from using the trunk instead.
Would a monthly release pattern reduce this gap to a point where
it would be possible to use the official Release as the actual
release?
I hope it's more clear
Jacques
Thanks,
Jacopo
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
