Le 02/07/2016 à 17:11, Sharan Foga a écrit :
Hi Jacques
No - I meant '..any' (I think positively positively :-)
BTW - I only use Pony Mail now for posting (not Nabble).
Hi Sharan,
Yikes, I wonder if others, apart Pierre, received your message. I still don't :/
Jacques
Thanks
Sharan
On
Hi Jacques
No - I meant '..any' (I think positively positively :-)
BTW - I only use Pony Mail now for posting (not Nabble).
Thanks
Sharan
On 2016-07-02 15:04 (+0200), Jacques Le Roux
wrote:
> Le 02/07/2016 � 11:55, Pierre Smits a �crit :
> > Our 15.12
Le 02/07/2016 à 11:55, Pierre Smits a écrit :
Our 15.12 branch was created in December 2015 and once again includes new
>features not present in 14.12 and any bug fixes. This has been maturing and
>stabilising for 6 months.
I guess here Sharan mean "...many bug fixes."
Jacques
I guess Sharan used Nabble, I did not see her message before writing mine.
Anyway still my opinion.
Jacques
Le 02/07/2016 à 11:55, Pierre Smits a écrit :
HI Charl, All,
To add to the thoughts shared by Sharan, the release branch 14.12 also
brought back components excluded in the 13.07
Hi Charl,
It's difficult to decide in your place, I see 2 possibilities.
1) stable but not up to date: pick R15 instead of R14. Since both will no longer be supported in 1 to 3 years without any package released, R15 seems
a better choice.
2) less stable but always up to date: trunk. From my
HI Charl, All,
To add to the thoughts shared by Sharan, the release branch 14.12 also
brought back components excluded in the 13.07 branch and releases. Our
release branches are not only for use of developers, but are intended to
cut releases from.
Also, the privileged contributors have - in
Hi Charl
I'm not a developer â so I hope that others will also respond on this with
their opinions too.
My thoughts are that you do have the option of basing your POC on either of our
two branches. Our branches are for the use of developers because it sounds like
you are going to do some
Hi all
Where does it leave a new user that is planning to become a contributor. I
am past the R stage and meeting my business partner next week to inform
him I already have 2 possibly 3 clients that is interested in a POC. In the
next month I am building a POC based on the 13.07 build.
I was
Hi Pierre
I'd be happy summarise what my understanding is, but beforehand I'd like to
point out that any decision on this discussion thread isn't âthe shared
conclusion of the PMCâ. The discussion was raised on this list specifically
to get feedback from our community and it's from that
It seems to me that Sharan is jumping the fence a bit to soon. Multiple
suggestions have gathered support.
This makes any 'this solution', without repeating what that solution is ,
multi-interpretable and would not only continue the discussion. But also
the confusion.
I suggest to repeat once
Hi Everyone
Thanks very much for the feedback. I'm glad that this solution will resolve our
current problems without taking away any functionality from the service
providers or developers that are using the unreleased branches.
Our next step will be to create and stabilise the 16.x release
Liked the idea Sharan +1
Best regards,
Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/
On Thu, Jun 30, 2016 at 2:30 PM, Ashish Vijaywargiya <
ashish.vijaywarg...@hotwaxsystems.com> wrote:
> +1, Very good idea. Thanks so much Sharan!
>
> Kind Regards
> Ashish Vijaywargiya
> HotWax
Great idea, +1
Michael Brohl
ecomify GmbH
www.ecomify.de
Am 30.06.16 um 09:05 schrieb Sharan Foga:
Thanks for the response -Jacopo. (You posted a minute before I did!)
Anyway I think that I might have an idea that could solve our problem – let's
just leave 14.12 and 15.12 as unreleased
+1, Very good idea. Thanks so much Sharan!
Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997
Connect with me on LinkedIn -
https://www.linkedin.com/in/ashishvijaywargiya1
On Thu, Jun 30, 2016 at 12:35 PM, Sharan Foga wrote:
> Thanks for the response -Jacopo. (You
+1
Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997
Connect with me on LinkedIn -
https://www.linkedin.com/in/ashishvijaywargiya1
On Thu, Jun 30, 2016 at 1:35 PM, Taher Alkhateeb wrote:
> Hi Sharan,
>
> Very smart idea simple and to the point. We avoid a
Hi Sharan,
Very smart idea simple and to the point. We avoid a mountain of work by
simply not releasing. I see two major benefits of not making a new releases
of 14 or 15
1- the compliance with no binaries issue for the ASF is automatically
achieved without any work
2- the community as a whole
Thanks for the response -Jacopo. (You posted a minute before I did!)
Anyway I think that I might have an idea that could solve our problem â let's
just leave 14.12 and 15.12 as unreleased branches.
The jar issue is only an issue if we want to convert the unreleased branches
into a release.
Hi Christian
Thanks for pointing out something very, very important and I agree with you.
I'm wondering if we still have a problem because even if we don't backport the
Gradle or start changes, before we can release 14.12 we need to make changes to
the way it handles external files (e.g the
On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
christian.geis...@isu-gmbh.de> wrote:
> ...
> My proposal is to release 14.12 ASAP, after that dropping 13.07 and then
> trying to do a release 16.x with Gradle. And a release of 15.12in
> between wouldn't be bad either ;)
>
>
Thank you
Thanks Christian, for this proposal.
I think this would be the best way to go and protect all user who relied
on the release branches as base of their projects.
+1
Regards,
Michael Brohl
ecomify GmbH
www.ecomify.de
Am 29.06.16 um 11:49 schrieb Christian Geisert:
While replacing Ant with
+1
Gil
On 29/06/2016 11:49, Christian Geisert wrote:
While replacing Ant with Gradle sounds like a good plan, I don't think
it's a good idea to backport these changes. Seriously, when implementing
OFBiz at a customer the only sane choice is to use a release branch
(even if there is no release
Sounds wise to me, thanks Christian!
Jacques
Le 29/06/2016 à 11:49, Christian Geisert a écrit :
While replacing Ant with Gradle sounds like a good plan, I don't think
it's a good idea to backport these changes. Seriously, when implementing
OFBiz at a customer the only sane choice is to use a
Le 29/06/2016 à 10:39, Jacques Le Roux a écrit :
Le 29/06/2016 à 08:33, Paul Piper a écrit :
1) release 14 to get away from 13
Agreed, I also proposed that before
Mmm, I re-read it, I actually followed Pierre's proposition about dropping R14
with R13. Sincerely I have not a strong opinion
While replacing Ant with Gradle sounds like a good plan, I don't think
it's a good idea to backport these changes. Seriously, when implementing
OFBiz at a customer the only sane choice is to use a release branch
(even if there is no release yet). The point of a release is to have a
stable
Inline...
Le 29/06/2016 à 08:33, Paul Piper a écrit :
1) release 14 to get away from 13
Agreed, I also proposed that before
2) use 15 for the gradle upgrade
+1, seems that we will need to backport start component changes as explained
Taher. Not a big deal, it's stable enough.
3) work
I agree with both the proposals. i.e :
1) Anticipate the end of life of the release branch 13.07 at now; we would
not issue the fourth release as initially planned.
2) Once stabilized, backport to 14.12 and 15.12 all the changes required to
build the system and download its dependencies with
Hey Folks,
So again another light bulb just hit me. But instead of modifying the build
script for the older releases we can just propagate all the changes that
happened to the start component because nobody touches the start component
that would make the backporting much easier to the older
Hi Folks,
I'm sorry I completely forgot to mention this in this thread but after
release 15 I think, I completely refactored the start component. This
refactoring changed the logic and the syntax for OFBiz startup and server
commands. This heavily affect the build system because it executes
Hi Todd
I think we'll need to wait for the outcome of this current discussion to
understand what will happen to the various 'unreleased releases'. So in
response to your question - the simple answer would be yes. Once this
discussion is over, we'll know what sort of transition we are looking
I don't think that my argument is a selfish one, Jacques. An end-of-life with
R13 is not my proposal, and neither are end of life of either 14 and 15. But
given the current direction of this conversation I am convinced that a
proper release plan is required and beneficial to all.
The current
Hi Paul,
I understand your concern, but seems to me that your answer is selfish. What about your comrades who have based their work on R13.07? They are in the
same situation than you!
OK this is kind of kidding, but see my point? ;)
A last point I always want to mention is, IMO, it's always
Hi all,
Not releasing 14 wouldn't make sense to me. Skipping releases never looks
good, as it either means that there hasn't been enough contributions or that
there are no proper release strategies in place. Neither make the community
or the or the product look good to outsiders.
I can
Hi Pierre,
This is not orthodox, but after being surprised by the idea of not releasing
R14, I think it make as much sense as not releasing R13.
We could then focus entirely on R15 and I'd even ask if we could not backport
the files moves, now only in trunk, to R15.
So we could then easily
+1 on putting the r13.07 branch out to the pasture, and bring the focus
towards r15 branch to cut a release soon.
+1 on putting the r14 branch out to the pasture, and bring the focus
towards r15 branch to cut a release soon.
+1 on focusing on getting the release from r15 out ASAP
Best regards,
Thanks for this, Mr. Foga. The Downloads page of the ofbiz.apache.org
site mentions 14.x and 15.x only as part of the project's tentative
release schedule. Would end user newcomers be wise to wait out the
transition?
On 16-06-28 09:55 AM, Sharan Foga wrote:
Thanks Jacopo for the details
Thanks Jacopo for the details and summary.
I know that some people might think it a bit strange that this discussion is
happening on the user list rather than the dev list, but I think these topics
are something that our users may have an opinion on and want to comment.
+1 for suggestion #1
+1 for the first
+1 for the second
It's important to keep consistency between projects !
On 28/06/2016 12:26, Jacopo Cappellato wrote:
Hi all,
as you may know we are working at migrating the build scripts of the OFBiz
trunk from Ant to Gradle.
Together with this important change we are also
Making perfect sense.
+1 for #1
+1 for #2
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Tue, Jun 28, 2016 at 5:19 PM, Ashish Vijaywargiya <
ashish.vijaywarg...@hotwaxsystems.com> wrote:
> +1 for #1.
> +1 for #2.
>
> Thanks Jacopo for the detailed email. It is very helpful!
>
> Kind
+1 for #1.
+1 for #2.
Thanks Jacopo for the detailed email. It is very helpful!
Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997
On Tue, Jun 28, 2016 at 3:56 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:
> Hi all,
>
> as you may know we are working at migrating
Hi Jacopo,
Making perfect sense to move this way-
+1 for #1
+1 for #2 as well.
Best regards,
Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/
On Tue, Jun 28, 2016 at 3:56 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:
> Hi all,
>
> as you may know we are
Thanks Jacopo for the thorough explanation.
I totally agree, R13.07 was born dead anyway and it will be less work to
backport.
I think though that we should release R14.12 ASAP in replacement of R13.07.
It's already waiting for 1.5 year...
+1 for the idea!
Jacques
Le 28/06/2016 à 13:07,
Hi Jacopo,
+1 for the first suggestion
+1 for the second suggestion
Although it is a bit more difficult to implement, it is beneficial on the
long run because it means a unified build system for all supported OFBiz
versions AND you also solve the ASF jar license issue. So strike two birds
with
Hi all,
as you may know we are working at migrating the build scripts of the OFBiz
trunk from Ant to Gradle.
Together with this important change we are also modifying, for policy
reasons, the way we distribute the external dependencies (i.e., the jar
files needed by OFBiz): the required jars will
43 matches
Mail list logo