Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-28 Thread Taher Alkhateeb
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 one stone

Cheers,

Taher Alkhateeb


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-28 Thread Jacques Le Roux

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, Taher Alkhateeb a écrit :

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 one stone

Cheers,

Taher Alkhateeb





Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-28 Thread Pranay Pandey
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 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 be downloaded at build time.
> Since these changes are not bug fixes, the current plan is to do these
> changes only in the trunk and do not backport them to the active branches,
> that are currently:
>
> * 13.07
> * 14.12
> * 15.12
>
> However, we will still have to modify these branches by removing the
> external jar files and download them using Ivy.
>
> The first concern is that we will have to work on and stabilize two fronts:
> Ivy for the 3 current release branches and Gradle for the trunk and the
> future branches.
> The second concern is that, as a consequence, we will have, for several
> years, significant differences in the setup/build steps between the old
> releases and the new ones that could cause confusion and regressions when
> bugs are backported.
>
> We have already issued 3 releases from the 13.07 branch and we have a
> tentative plan to issue one more release around February 2017 that would be
> the last release of this series.
> As regards 14.12 and 15.12 branches, no releases have been issued yet.
>
> Based on these details I would like you to consider the following
> decisions:
>
> 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 Gradle
>
> Please express your opinion on each of them separately, since they are
> independent (i.e., you could agree/disagree on the first/second/both).
>
> Thanks,
>
> Jacopo
>


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-28 Thread Ashish Vijaywargiya
+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 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 be downloaded at build time.
> Since these changes are not bug fixes, the current plan is to do these
> changes only in the trunk and do not backport them to the active branches,
> that are currently:
>
> * 13.07
> * 14.12
> * 15.12
>
> However, we will still have to modify these branches by removing the
> external jar files and download them using Ivy.
>
> The first concern is that we will have to work on and stabilize two fronts:
> Ivy for the 3 current release branches and Gradle for the trunk and the
> future branches.
> The second concern is that, as a consequence, we will have, for several
> years, significant differences in the setup/build steps between the old
> releases and the new ones that could cause confusion and regressions when
> bugs are backported.
>
> We have already issued 3 releases from the 13.07 branch and we have a
> tentative plan to issue one more release around February 2017 that would be
> the last release of this series.
> As regards 14.12 and 15.12 branches, no releases have been issued yet.
>
> Based on these details I would like you to consider the following
> decisions:
>
> 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 Gradle
>
> Please express your opinion on each of them separately, since they are
> independent (i.e., you could agree/disagree on the first/second/both).
>
> Thanks,
>
> Jacopo
>


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-28 Thread Deepak Dixit
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 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 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 be downloaded at build
> time.
> > Since these changes are not bug fixes, the current plan is to do these
> > changes only in the trunk and do not backport them to the active
> branches,
> > that are currently:
> >
> > * 13.07
> > * 14.12
> > * 15.12
> >
> > However, we will still have to modify these branches by removing the
> > external jar files and download them using Ivy.
> >
> > The first concern is that we will have to work on and stabilize two
> fronts:
> > Ivy for the 3 current release branches and Gradle for the trunk and the
> > future branches.
> > The second concern is that, as a consequence, we will have, for several
> > years, significant differences in the setup/build steps between the old
> > releases and the new ones that could cause confusion and regressions when
> > bugs are backported.
> >
> > We have already issued 3 releases from the 13.07 branch and we have a
> > tentative plan to issue one more release around February 2017 that would
> be
> > the last release of this series.
> > As regards 14.12 and 15.12 branches, no releases have been issued yet.
> >
> > Based on these details I would like you to consider the following
> > decisions:
> >
> > 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 Gradle
> >
> > Please express your opinion on each of them separately, since they are
> > independent (i.e., you could agree/disagree on the first/second/both).
> >
> > Thanks,
> >
> > Jacopo
> >
>


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-28 Thread Julien NICOLAS

+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 modifying, for policy
reasons, the way we distribute the external dependencies (i.e., the jar
files needed by OFBiz): the required jars will be downloaded at build time.
Since these changes are not bug fixes, the current plan is to do these
changes only in the trunk and do not backport them to the active branches,
that are currently:

* 13.07
* 14.12
* 15.12

However, we will still have to modify these branches by removing the
external jar files and download them using Ivy.

The first concern is that we will have to work on and stabilize two fronts:
Ivy for the 3 current release branches and Gradle for the trunk and the
future branches.
The second concern is that, as a consequence, we will have, for several
years, significant differences in the setup/build steps between the old
releases and the new ones that could cause confusion and regressions when
bugs are backported.

We have already issued 3 releases from the 13.07 branch and we have a
tentative plan to issue one more release around February 2017 that would be
the last release of this series.
As regards 14.12 and 15.12 branches, no releases have been issued yet.

Based on these details I would like you to consider the following decisions:

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 Gradle

Please express your opinion on each of them separately, since they are
independent (i.e., you could agree/disagree on the first/second/both).

Thanks,

Jacopo





Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-28 Thread Sharan Foga
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

13.07 has been around a while so I think that ending it now rather than next 
year will help us to focus on other work (e.g. refactoring and clean up)

+1 for suggestion #2

I think the work we are currently doing to improve the trunk build system isn't 
really that visible to our users, but it will make a big difference to 
developers and people who administer the system. Pushing those technical 
benefits back to 14.12 and 15.12 (if we still want to call them that!) will 
help.

Also OFBiz has changed a lot since the 14.12 and even 15.12 branches were 
created. We've incorporated so much new functionality that it would be a good 
thing to try and get some of this into our next release. Essentially it would 
mean more functionality for our users.

Thanks 
Sharan

On 2016-06-28 12:26 (+0200), 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 modifying, for policy
> reasons, the way we distribute the external dependencies (i.e., the jar
> files needed by OFBiz): the required jars will be downloaded at build time.
> Since these changes are not bug fixes, the current plan is to do these
> changes only in the trunk and do not backport them to the active branches,
> that are currently:
> 
> * 13.07
> * 14.12
> * 15.12
> 
> However, we will still have to modify these branches by removing the
> external jar files and download them using Ivy.
> 
> The first concern is that we will have to work on and stabilize two fronts:
> Ivy for the 3 current release branches and Gradle for the trunk and the
> future branches.
> The second concern is that, as a consequence, we will have, for several
> years, significant differences in the setup/build steps between the old
> releases and the new ones that could cause confusion and regressions when
> bugs are backported.
> 
> We have already issued 3 releases from the 13.07 branch and we have a
> tentative plan to issue one more release around February 2017 that would be
> the last release of this series.
> As regards 14.12 and 15.12 branches, no releases have been issued yet.
> 
> Based on these details I would like you to consider the following decisions:
> 
> 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 Gradle
> 
> Please express your opinion on each of them separately, since they are
> independent (i.e., you could agree/disagree on the first/second/both).
> 
> Thanks,
> 
> Jacopo
> 


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-28 Thread Todd Thorner
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 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

13.07 has been around a while so I think that ending it now rather than next 
year will help us to focus on other work (e.g. refactoring and clean up)

+1 for suggestion #2

I think the work we are currently doing to improve the trunk build system isn't 
really that visible to our users, but it will make a big difference to 
developers and people who administer the system. Pushing those technical 
benefits back to 14.12 and 15.12 (if we still want to call them that!) will 
help.

Also OFBiz has changed a lot since the 14.12 and even 15.12 branches were 
created. We've incorporated so much new functionality that it would be a good 
thing to try and get some of this into our next release. Essentially it would 
mean more functionality for our users.

Thanks
Sharan

On 2016-06-28 12:26 (+0200), 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 modifying, for policy
reasons, the way we distribute the external dependencies (i.e., the jar
files needed by OFBiz): the required jars will be downloaded at build time.
Since these changes are not bug fixes, the current plan is to do these
changes only in the trunk and do not backport them to the active branches,
that are currently:

* 13.07
* 14.12
* 15.12

However, we will still have to modify these branches by removing the
external jar files and download them using Ivy.

The first concern is that we will have to work on and stabilize two fronts:
Ivy for the 3 current release branches and Gradle for the trunk and the
future branches.
The second concern is that, as a consequence, we will have, for several
years, significant differences in the setup/build steps between the old
releases and the new ones that could cause confusion and regressions when
bugs are backported.

We have already issued 3 releases from the 13.07 branch and we have a
tentative plan to issue one more release around February 2017 that would be
the last release of this series.
As regards 14.12 and 15.12 branches, no releases have been issued yet.

Based on these details I would like you to consider the following decisions:

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 Gradle

Please express your opinion on each of them separately, since they are
independent (i.e., you could agree/disagree on the first/second/both).

Thanks,

Jacopo





Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-28 Thread Pierre Smits
+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,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jun 28, 2016 at 7:32 PM, Todd Thorner 
wrote:

> 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 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
>>
>> 13.07 has been around a while so I think that ending it now rather than
>> next year will help us to focus on other work (e.g. refactoring and clean
>> up)
>>
>> +1 for suggestion #2
>>
>> I think the work we are currently doing to improve the trunk build system
>> isn't really that visible to our users, but it will make a big difference
>> to developers and people who administer the system. Pushing those technical
>> benefits back to 14.12 and 15.12 (if we still want to call them that!) will
>> help.
>>
>> Also OFBiz has changed a lot since the 14.12 and even 15.12 branches were
>> created. We've incorporated so much new functionality that it would be a
>> good thing to try and get some of this into our next release. Essentially
>> it would mean more functionality for our users.
>>
>> Thanks
>> Sharan
>>
>> On 2016-06-28 12:26 (+0200), Jacopo Cappellato <
>> jacopo.cappell...@hotwaxsystems.com> 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 modifying, for policy
>>> reasons, the way we distribute the external dependencies (i.e., the jar
>>> files needed by OFBiz): the required jars will be downloaded at build
>>> time.
>>> Since these changes are not bug fixes, the current plan is to do these
>>> changes only in the trunk and do not backport them to the active
>>> branches,
>>> that are currently:
>>>
>>> * 13.07
>>> * 14.12
>>> * 15.12
>>>
>>> However, we will still have to modify these branches by removing the
>>> external jar files and download them using Ivy.
>>>
>>> The first concern is that we will have to work on and stabilize two
>>> fronts:
>>> Ivy for the 3 current release branches and Gradle for the trunk and the
>>> future branches.
>>> The second concern is that, as a consequence, we will have, for several
>>> years, significant differences in the setup/build steps between the old
>>> releases and the new ones that could cause confusion and regressions when
>>> bugs are backported.
>>>
>>> We have already issued 3 releases from the 13.07 branch and we have a
>>> tentative plan to issue one more release around February 2017 that would
>>> be
>>> the last release of this series.
>>> As regards 14.12 and 15.12 branches, no releases have been issued yet.
>>>
>>> Based on these details I would like you to consider the following
>>> decisions:
>>>
>>> 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 Gradle
>>>
>>> Please express your opinion on each of them separately, since they are
>>> independent (i.e., you could agree/disagree on the first/second/both).
>>>
>>> Thanks,
>>>
>>> Jacopo
>>>
>>>
>


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-28 Thread Jacques Le Roux

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 backport the changes in those files. It seems those moves went well, which is actually not surprising since apart typos we 
could not expect much issues.


Another possibility would be to soon freeze a R16 branch, once the Gradle use 
will have been validated for instance.

Opinions?

Jacques

Le 28/06/2016 à 20:09, Pierre Smits a écrit :

+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,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jun 28, 2016 at 7:32 PM, Todd Thorner 
wrote:


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 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

13.07 has been around a while so I think that ending it now rather than
next year will help us to focus on other work (e.g. refactoring and clean
up)

+1 for suggestion #2

I think the work we are currently doing to improve the trunk build system
isn't really that visible to our users, but it will make a big difference
to developers and people who administer the system. Pushing those technical
benefits back to 14.12 and 15.12 (if we still want to call them that!) will
help.

Also OFBiz has changed a lot since the 14.12 and even 15.12 branches were
created. We've incorporated so much new functionality that it would be a
good thing to try and get some of this into our next release. Essentially
it would mean more functionality for our users.

Thanks
Sharan

On 2016-06-28 12:26 (+0200), Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> 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 modifying, for policy
reasons, the way we distribute the external dependencies (i.e., the jar
files needed by OFBiz): the required jars will be downloaded at build
time.
Since these changes are not bug fixes, the current plan is to do these
changes only in the trunk and do not backport them to the active
branches,
that are currently:

* 13.07
* 14.12
* 15.12

However, we will still have to modify these branches by removing the
external jar files and download them using Ivy.

The first concern is that we will have to work on and stabilize two
fronts:
Ivy for the 3 current release branches and Gradle for the trunk and the
future branches.
The second concern is that, as a consequence, we will have, for several
years, significant differences in the setup/build steps between the old
releases and the new ones that could cause confusion and regressions when
bugs are backported.

We have already issued 3 releases from the 13.07 branch and we have a
tentative plan to issue one more release around February 2017 that would
be
the last release of this series.
As regards 14.12 and 15.12 branches, no releases have been issued yet.

Based on these details I would like you to consider the following
decisions:

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 Gradle

Please express your opinion on each of them separately, since they are
independent (i.e., you could agree/disagree on the first/second/both).

Thanks,

Jacopo






Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-28 Thread Paul Piper
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 understand that one would want to drop support for 13, but i would
argue that at least 14 should be kept as it seems stable and could act as a
version that eases the transition to gradle. Then 15 would be 14 + gradle
support and 16 a proper new release. 

The reason i argue for this is also that our client installations rely on
some sort of migration plan. Just calling end-of-life on a product and then
moving forwards is hell for them, as it practically means that they will
have to pay for a more stressful migration if they want to keep receiving
security bugfixes. 

So i hope i can convince the rest of you to think this over. 

Regards,
Paul




--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/DISCUSSION-Anticipate-the-end-of-life-of-the-13-07-branch-and-backport-some-non-bug-related-changes-s-tp4686668p4686803.html
Sent from the OFBiz - User mailing list archive at Nabble.com.


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-28 Thread Jacques Le Roux

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 better to use a branch by directly connecting your work with svn than using a packaged 
version. So a compromise would be that instead of using the packaged release, people in your situation could consider connecting their work to svn at 
the point (revision) the package they use was created. They would then get the same situation but iwould be able to easier follow the work done by the 
community. We would then continue to backport in these branches, opinions?


Cheers

Jacques


Le 28/06/2016 à 22:58, Paul Piper a écrit :

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 understand that one would want to drop support for 13, but i would
argue that at least 14 should be kept as it seems stable and could act as a
version that eases the transition to gradle. Then 15 would be 14 + gradle
support and 16 a proper new release.

The reason i argue for this is also that our client installations rely on
some sort of migration plan. Just calling end-of-life on a product and then
moving forwards is hell for them, as it practically means that they will
have to pay for a more stressful migration if they want to keep receiving
security bugfixes.

So i hope i can convince the rest of you to think this over.

Regards,
Paul




--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/DISCUSSION-Anticipate-the-end-of-life-of-the-13-07-branch-and-backport-some-non-bug-related-changes-s-tp4686668p4686803.html
Sent from the OFBiz - User mailing list archive at Nabble.com.





Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-29 Thread Paul Piper
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 release promoted up on the website is 13. Calling it quits on it
before you even have as much as a next release is not only confusing but
also quite unfair to all the people who are basing their work on it. I don't
necessarily cling onto any of these versions (as i stated before, i don't
see too much difference functionality wise between 9-13), but I do think
that a migration plan is the decent thing to do. In particular if you
promote the idea of people having to keep up with trunk or any of the svn
repositories (which frankly is a matter of time&money) you should allow
people a transition phase. 

Having seen the community promoted 14 and 15 as branches before (instead of
the packages), i would argue that perhaps there is a way to keep a straight
face while working on a grander release - namely version 16: 

1) release 14 to get away from 13 
2) use 15 for the gradle upgrade
3) work on 16 as a proper feature release



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/DISCUSSION-Anticipate-the-end-of-life-of-the-13-07-branch-and-backport-some-non-bug-related-changes-s-tp4686668p4686844.html
Sent from the OFBiz - User mailing list archive at Nabble.com.


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-29 Thread Sharan Foga
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 at.

(BTW our website needs updating and I'm currently working on re-writing it 
completely.)

Thanks
Sharan

On 2016-06-28 19:32 (+0200), Todd Thorner  wrote: 
> 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 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
> >
> > 13.07 has been around a while so I think that ending it now rather than 
> > next year will help us to focus on other work (e.g. refactoring and clean 
> > up)
> >
> > +1 for suggestion #2
> >
> > I think the work we are currently doing to improve the trunk build system 
> > isn't really that visible to our users, but it will make a big difference 
> > to developers and people who administer the system. Pushing those technical 
> > benefits back to 14.12 and 15.12 (if we still want to call them that!) will 
> > help.
> >
> > Also OFBiz has changed a lot since the 14.12 and even 15.12 branches were 
> > created. We've incorporated so much new functionality that it would be a 
> > good thing to try and get some of this into our next release. Essentially 
> > it would mean more functionality for our users.
> >
> > Thanks
> > Sharan
> >
> > On 2016-06-28 12:26 (+0200), 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 modifying, for policy
> >> reasons, the way we distribute the external dependencies (i.e., the jar
> >> files needed by OFBiz): the required jars will be downloaded at build time.
> >> Since these changes are not bug fixes, the current plan is to do these
> >> changes only in the trunk and do not backport them to the active branches,
> >> that are currently:
> >>
> >> * 13.07
> >> * 14.12
> >> * 15.12
> >>
> >> However, we will still have to modify these branches by removing the
> >> external jar files and download them using Ivy.
> >>
> >> The first concern is that we will have to work on and stabilize two fronts:
> >> Ivy for the 3 current release branches and Gradle for the trunk and the
> >> future branches.
> >> The second concern is that, as a consequence, we will have, for several
> >> years, significant differences in the setup/build steps between the old
> >> releases and the new ones that could cause confusion and regressions when
> >> bugs are backported.
> >>
> >> We have already issued 3 releases from the 13.07 branch and we have a
> >> tentative plan to issue one more release around February 2017 that would be
> >> the last release of this series.
> >> As regards 14.12 and 15.12 branches, no releases have been issued yet.
> >>
> >> Based on these details I would like you to consider the following 
> >> decisions:
> >>
> >> 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 Gradle
> >>
> >> Please express your opinion on each of them separately, since they are
> >> independent (i.e., you could agree/disagree on the first/second/both).
> >>
> >> Thanks,
> >>
> >> Jacopo
> >>
> 
> 


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-29 Thread Taher Alkhateeb
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 server
commands.

So if we decide to backport gradle to older releases then it's not going to
be a straight copy and paste exercise but there will be modifications to
comply with the old syntax of the startup logic.

This is for your information on how we decide to move forward. I still like
the idea to switch to Gradle for all releases but its necessary for me to
State that there will be consequences in time and effort in doing that.

Regards,
Taher Alkhateeb
On Jun 29, 2016 10:24 AM, "Sharan Foga"  wrote:

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 at.

(BTW our website needs updating and I'm currently working on re-writing it
completely.)

Thanks
Sharan

On 2016-06-28 19:32 (+0200), Todd Thorner  wrote:
> 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 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
> >
> > 13.07 has been around a while so I think that ending it now rather than
next year will help us to focus on other work (e.g. refactoring and clean
up)
> >
> > +1 for suggestion #2
> >
> > I think the work we are currently doing to improve the trunk build
system isn't really that visible to our users, but it will make a big
difference to developers and people who administer the system. Pushing
those technical benefits back to 14.12 and 15.12 (if we still want to call
them that!) will help.
> >
> > Also OFBiz has changed a lot since the 14.12 and even 15.12 branches
were created. We've incorporated so much new functionality that it would be
a good thing to try and get some of this into our next release. Essentially
it would mean more functionality for our users.
> >
> > Thanks
> > Sharan
> >
> > On 2016-06-28 12:26 (+0200), Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> 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 modifying, for policy
> >> reasons, the way we distribute the external dependencies (i.e., the jar
> >> files needed by OFBiz): the required jars will be downloaded at build
time.
> >> Since these changes are not bug fixes, the current plan is to do these
> >> changes only in the trunk and do not backport them to the active
branches,
> >> that are currently:
> >>
> >> * 13.07
> >> * 14.12
> >> * 15.12
> >>
> >> However, we will still have to modify these branches by removing the
> >> external jar files and download them using Ivy.
> >>
> >> The first concern is that we will have to work on and stabilize two
fronts:
> >> Ivy for the 3 current release branches and Gradle for the trunk and the
> >> future branches.
> >> The second concern is that, as a consequence, we will have, for several
> >> years, significant differences in the setup/build steps between the old
> >> releases and the new ones that could cause confusion and regressions
when
> >> bugs are backported.
> >>
> >> We have already issued 3 releases from the 13.07 branch and we have a
> >> tentative plan to issue one more release around February 2017 that
would be
> >> the last release of this series.
> >> As regards 14.12 and 15.12 branches, no releases have been issued yet.
> >>
> >> Based on these details I would like you to consider the following
decisions:
> >>
> >> 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 Gradle
> >>
> >> Please express your opinion on each of them separately, since they are
> >> independent (i.e., you could agree/disagree on the first/second/both).
> >>
> >> Thanks,
> >>
> >> Jacopo
> >>
>
>


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-29 Thread Taher Alkhateeb
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 releases.

Regards,

Taher Alkhateeb
On Jun 29, 2016 10:47 AM, "Taher Alkhateeb" 
wrote:

> 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 server
> commands.
>
> So if we decide to backport gradle to older releases then it's not going
> to be a straight copy and paste exercise but there will be modifications to
> comply with the old syntax of the startup logic.
>
> This is for your information on how we decide to move forward. I still
> like the idea to switch to Gradle for all releases but its necessary for me
> to State that there will be consequences in time and effort in doing that.
>
> Regards,
> Taher Alkhateeb
> On Jun 29, 2016 10:24 AM, "Sharan Foga"  wrote:
>
> 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 at.
>
> (BTW our website needs updating and I'm currently working on re-writing it
> completely.)
>
> Thanks
> Sharan
>
> On 2016-06-28 19:32 (+0200), Todd Thorner  wrote:
> > 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 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
> > >
> > > 13.07 has been around a while so I think that ending it now rather
> than next year will help us to focus on other work (e.g. refactoring and
> clean up)
> > >
> > > +1 for suggestion #2
> > >
> > > I think the work we are currently doing to improve the trunk build
> system isn't really that visible to our users, but it will make a big
> difference to developers and people who administer the system. Pushing
> those technical benefits back to 14.12 and 15.12 (if we still want to call
> them that!) will help.
> > >
> > > Also OFBiz has changed a lot since the 14.12 and even 15.12 branches
> were created. We've incorporated so much new functionality that it would be
> a good thing to try and get some of this into our next release. Essentially
> it would mean more functionality for our users.
> > >
> > > Thanks
> > > Sharan
> > >
> > > On 2016-06-28 12:26 (+0200), Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> 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 modifying, for policy
> > >> reasons, the way we distribute the external dependencies (i.e., the
> jar
> > >> files needed by OFBiz): the required jars will be downloaded at build
> time.
> > >> Since these changes are not bug fixes, the current plan is to do these
> > >> changes only in the trunk and do not backport them to the active
> branches,
> > >> that are currently:
> > >>
> > >> * 13.07
> > >> * 14.12
> > >> * 15.12
> > >>
> > >> However, we will still have to modify these branches by removing the
> > >> external jar files and download them using Ivy.
> > >>
> > >> The first concern is that we will have to work on and stabilize two
> fronts:
> > >> Ivy for the 3 current release branches and Gradle for the trunk and
> the
> > >> future branches.
> > >> The second concern is that, as a consequence, we will have, for
> several
> > >> years, significant differences in the setup/build steps between the
> old
> > >> releases and the new ones that could cause confusion and regressions
> when
> > >> bugs are backported.
> > >>
> > >> We have already issued 3 releases from the 13.07 branch and we have a
> > >> tentative plan to issue one more release around February 2017 that
> would be
> > >> the last release of this series.
> > >> As regards 14.12 and 15.12 branches, no releases have been issued yet.
> > >>
> > >> Based on these details I would like you to consider the following
> decisions:
> > >>
> > >> 1) anticipate the end of life of the release branch 13.07 at now; we
> would
> > >> not issue the fou

Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-29 Thread Divesh Dutta
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 Gradle.

Thanks
--
Divesh Dutta.

On Wed, Jun 29, 2016 at 2:28 AM, Paul Piper  wrote:

> 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 understand that one would want to drop support for 13, but i would
> argue that at least 14 should be kept as it seems stable and could act as a
> version that eases the transition to gradle. Then 15 would be 14 + gradle
> support and 16 a proper new release.
>
> The reason i argue for this is also that our client installations rely on
> some sort of migration plan. Just calling end-of-life on a product and then
> moving forwards is hell for them, as it practically means that they will
> have to pay for a more stressful migration if they want to keep receiving
> security bugfixes.
>
> So i hope i can convince the rest of you to think this over.
>
> Regards,
> Paul
>
>
>
>
> --
> View this message in context:
> http://ofbiz.135035.n4.nabble.com/DISCUSSION-Anticipate-the-end-of-life-of-the-13-07-branch-and-backport-some-non-bug-related-changes-s-tp4686668p4686803.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-29 Thread Jacques Le Roux

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 on 16 as a proper feature release


Yes, I also proposed that before

Jacques



Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-29 Thread Christian Geisert
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 codebase, and porting the Gradle stuff (including changes in
startup etc.) to the release branches will cause instability.
Additionally, It will take quite some time before these changes will be
done in trunk. Releasing 14.12 and 15.12 without the changes and then
later doing a minor release with the changes would be bad.

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 ;)

Christian

Am 28.06.2016 12:26, schrieb Jacopo Cappellato:
> 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 be downloaded at build time.
> Since these changes are not bug fixes, the current plan is to do these
> changes only in the trunk and do not backport them to the active branches,
> that are currently:
>
> * 13.07
> * 14.12
> * 15.12
>
> However, we will still have to modify these branches by removing the
> external jar files and download them using Ivy.
>
> The first concern is that we will have to work on and stabilize two fronts:
> Ivy for the 3 current release branches and Gradle for the trunk and the
> future branches.
> The second concern is that, as a consequence, we will have, for several
> years, significant differences in the setup/build steps between the old
> releases and the new ones that could cause confusion and regressions when
> bugs are backported.
>
> We have already issued 3 releases from the 13.07 branch and we have a
> tentative plan to issue one more release around February 2017 that would be
> the last release of this series.
> As regards 14.12 and 15.12 branches, no releases have been issued yet.
>
> Based on these details I would like you to consider the following decisions:
>
> 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 Gradle
>
> Please express your opinion on each of them separately, since they are
> independent (i.e., you could agree/disagree on the first/second/both).
>
> Thanks,
>
> Jacopo
>



Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-29 Thread Jacques Le Roux

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 about that.
It's more related with the work and energy behind it. I mean volunteers working 
for free, to get the better result for the whole community

Jacques



Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-29 Thread Jacques Le Roux

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 release branch
(even if there is no release yet). The point of a release is to have a
stable codebase, and porting the Gradle stuff (including changes in
startup etc.) to the release branches will cause instability.
Additionally, It will take quite some time before these changes will be
done in trunk. Releasing 14.12 and 15.12 without the changes and then
later doing a minor release with the changes would be bad.

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 ;)

Christian

Am 28.06.2016 12:26, schrieb Jacopo Cappellato:

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 be downloaded at build time.
Since these changes are not bug fixes, the current plan is to do these
changes only in the trunk and do not backport them to the active branches,
that are currently:

* 13.07
* 14.12
* 15.12

However, we will still have to modify these branches by removing the
external jar files and download them using Ivy.

The first concern is that we will have to work on and stabilize two fronts:
Ivy for the 3 current release branches and Gradle for the trunk and the
future branches.
The second concern is that, as a consequence, we will have, for several
years, significant differences in the setup/build steps between the old
releases and the new ones that could cause confusion and regressions when
bugs are backported.

We have already issued 3 releases from the 13.07 branch and we have a
tentative plan to issue one more release around February 2017 that would be
the last release of this series.
As regards 14.12 and 15.12 branches, no releases have been issued yet.

Based on these details I would like you to consider the following decisions:

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 Gradle

Please express your opinion on each of them separately, since they are
independent (i.e., you could agree/disagree on the first/second/both).

Thanks,

Jacopo







Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-29 Thread gil portenseigne

+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 yet). The point of a release is to have a
stable codebase, and porting the Gradle stuff (including changes in
startup etc.) to the release branches will cause instability.
Additionally, It will take quite some time before these changes will be
done in trunk. Releasing 14.12 and 15.12 without the changes and then
later doing a minor release with the changes would be bad.

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 ;)

Christian

Am 28.06.2016 12:26, schrieb Jacopo Cappellato:

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 be downloaded at build time.
Since these changes are not bug fixes, the current plan is to do these
changes only in the trunk and do not backport them to the active branches,
that are currently:

* 13.07
* 14.12
* 15.12

However, we will still have to modify these branches by removing the
external jar files and download them using Ivy.

The first concern is that we will have to work on and stabilize two fronts:
Ivy for the 3 current release branches and Gradle for the trunk and the
future branches.
The second concern is that, as a consequence, we will have, for several
years, significant differences in the setup/build steps between the old
releases and the new ones that could cause confusion and regressions when
bugs are backported.

We have already issued 3 releases from the 13.07 branch and we have a
tentative plan to issue one more release around February 2017 that would be
the last release of this series.
As regards 14.12 and 15.12 branches, no releases have been issued yet.

Based on these details I would like you to consider the following decisions:

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 Gradle

Please express your opinion on each of them separately, since they are
independent (i.e., you could agree/disagree on the first/second/both).

Thanks,

Jacopo





Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-29 Thread Michael Brohl

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 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 codebase, and porting the Gradle stuff (including changes in
startup etc.) to the release branches will cause instability.
Additionally, It will take quite some time before these changes will be
done in trunk. Releasing 14.12 and 15.12 without the changes and then
later doing a minor release with the changes would be bad.

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 ;)

Christian

Am 28.06.2016 12:26, schrieb Jacopo Cappellato:

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 be downloaded at build time.
Since these changes are not bug fixes, the current plan is to do these
changes only in the trunk and do not backport them to the active branches,
that are currently:

* 13.07
* 14.12
* 15.12

However, we will still have to modify these branches by removing the
external jar files and download them using Ivy.

The first concern is that we will have to work on and stabilize two fronts:
Ivy for the 3 current release branches and Gradle for the trunk and the
future branches.
The second concern is that, as a consequence, we will have, for several
years, significant differences in the setup/build steps between the old
releases and the new ones that could cause confusion and regressions when
bugs are backported.

We have already issued 3 releases from the 13.07 branch and we have a
tentative plan to issue one more release around February 2017 that would be
the last release of this series.
As regards 14.12 and 15.12 branches, no releases have been issued yet.

Based on these details I would like you to consider the following decisions:

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 Gradle

Please express your opinion on each of them separately, since they are
independent (i.e., you could agree/disagree on the first/second/both).

Thanks,

Jacopo






smime.p7s
Description: S/MIME Cryptographic Signature


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-29 Thread Jacopo Cappellato
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 Christian.
Your proposal makes sense but the problem is that we will not be able to
release (14.12, 15.12 etc...) until we have removed all the jars from the
distribution, and implementing this in the branches will require some
layout changes that will bring instability: the releases will be delayed
regardless and if we want to implement two different mechanisms for
downloading the jars for 14.12 vs the trunk and 16.x etc... than the
codebases will become rather different and more difficult to maintain; and
the extra effort will have to be backed up by the interested users. We have
to consider these aspects and do a reality check on resources before moving
in any direction.

Jacopo


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-29 Thread Sharan Foga
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 jar files) – and at the moment 
that means doing the changes using Ivy.  Do you think that the proposed Ivy 
changes that are a pre-requisite to the release of 14.12 would also cause this 
instability? 

Thanks
Sharan

On 2016-06-29 11:49 (+0200), 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 yet). The point of a release is to have a
> stable codebase, and porting the Gradle stuff (including changes in
> startup etc.) to the release branches will cause instability.
> Additionally, It will take quite some time before these changes will be
> done in trunk. Releasing 14.12 and 15.12 without the changes and then
> later doing a minor release with the changes would be bad.
> 
> 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 ;)
> 
> Christian
> 
> Am 28.06.2016 12:26, schrieb Jacopo Cappellato:
> > 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 be downloaded at build time.
> > Since these changes are not bug fixes, the current plan is to do these
> > changes only in the trunk and do not backport them to the active branches,
> > that are currently:
> >
> > * 13.07
> > * 14.12
> > * 15.12
> >
> > However, we will still have to modify these branches by removing the
> > external jar files and download them using Ivy.
> >
> > The first concern is that we will have to work on and stabilize two fronts:
> > Ivy for the 3 current release branches and Gradle for the trunk and the
> > future branches.
> > The second concern is that, as a consequence, we will have, for several
> > years, significant differences in the setup/build steps between the old
> > releases and the new ones that could cause confusion and regressions when
> > bugs are backported.
> >
> > We have already issued 3 releases from the 13.07 branch and we have a
> > tentative plan to issue one more release around February 2017 that would be
> > the last release of this series.
> > As regards 14.12 and 15.12 branches, no releases have been issued yet.
> >
> > Based on these details I would like you to consider the following decisions:
> >
> > 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 Gradle
> >
> > Please express your opinion on each of them separately, since they are
> > independent (i.e., you could agree/disagree on the first/second/both).
> >
> > Thanks,
> >
> > Jacopo
> >
> 
> 


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-30 Thread 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 branches.

The jar issue is only an issue if we want to convert the unreleased branches 
into a release. Unreleased they can contain the jar files and the special 
purpose components etc – but if we want to release them then we need to fix 
the jar file problem before it can be released.

Christian mentions that people are using the unreleased branches, so by leaving 
them unreleased, we are actually giving our users something that can help them 
move from 13.07. 

So I suggest that we seriously consider leaving 14.12 and 15.12 as unreleased 
branches.

For the next point – I think our next release should be the 16.x – so that 
means that we are not backporting any changes and can take a branch directly 
from the trunk once the gradle changes have been applied.

Comments anyone?

Thanks
Sharan


On 2016-06-30 07:25 (+0200), Jacopo Cappellato 
 wrote: 
> 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 Christian.
> Your proposal makes sense but the problem is that we will not be able to
> release (14.12, 15.12 etc...) until we have removed all the jars from the
> distribution, and implementing this in the branches will require some
> layout changes that will bring instability: the releases will be delayed
> regardless and if we want to implement two different mechanisms for
> downloading the jars for 14.12 vs the trunk and 16.x etc... than the
> codebases will become rather different and more difficult to maintain; and
> the extra effort will have to be backed up by the interested users. We have
> to consider these aspects and do a reality check on resources before moving
> in any direction.
> 
> Jacopo
> 


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-30 Thread Taher Alkhateeb
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 can now focus on the future by upgrading and
migrating to the new releases where all the hot stuff is happening

Under the special circumstances we are going through with this wake up call
to refactor and improve the framework and the big new features being added
it makes sense to unify our efforts.

With that being said we need to focus our efforts on making a new release
soon to have something tangible with all the goodies in the hands of our
users.

Taher Alkhateeb
On Jun 30, 2016 10:05 AM, "Sharan Foga"  wrote:

> 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. Unreleased they can contain the jar files and the
> special purpose components etc – but if we want to release them then we
> need to fix the jar file problem before it can be released.
>
> Christian mentions that people are using the unreleased branches, so by
> leaving them unreleased, we are actually giving our users something that
> can help them move from 13.07.
>
> So I suggest that we seriously consider leaving 14.12 and 15.12 as
> unreleased branches.
>
> For the next point – I think our next release should be the 16.x – so that
> means that we are not backporting any changes and can take a branch
> directly from the trunk once the gradle changes have been applied.
>
> Comments anyone?
>
> Thanks
> Sharan
>
>
> On 2016-06-30 07:25 (+0200), Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
> > 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 Christian.
> > Your proposal makes sense but the problem is that we will not be able to
> > release (14.12, 15.12 etc...) until we have removed all the jars from the
> > distribution, and implementing this in the branches will require some
> > layout changes that will bring instability: the releases will be delayed
> > regardless and if we want to implement two different mechanisms for
> > downloading the jars for 14.12 vs the trunk and 16.x etc... than the
> > codebases will become rather different and more difficult to maintain;
> and
> > the extra effort will have to be backed up by the interested users. We
> have
> > to consider these aspects and do a reality check on resources before
> moving
> > in any direction.
> >
> > Jacopo
> >
>


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-30 Thread Ashish Vijaywargiya
+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 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 can now focus on the future by upgrading and
> migrating to the new releases where all the hot stuff is happening
>
> Under the special circumstances we are going through with this wake up call
> to refactor and improve the framework and the big new features being added
> it makes sense to unify our efforts.
>
> With that being said we need to focus our efforts on making a new release
> soon to have something tangible with all the goodies in the hands of our
> users.
>
> Taher Alkhateeb
> On Jun 30, 2016 10:05 AM, "Sharan Foga"  wrote:
>
> > 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. Unreleased they can contain the jar files and
> the
> > special purpose components etc – but if we want to release them then we
> > need to fix the jar file problem before it can be released.
> >
> > Christian mentions that people are using the unreleased branches, so by
> > leaving them unreleased, we are actually giving our users something that
> > can help them move from 13.07.
> >
> > So I suggest that we seriously consider leaving 14.12 and 15.12 as
> > unreleased branches.
> >
> > For the next point – I think our next release should be the 16.x – so
> that
> > means that we are not backporting any changes and can take a branch
> > directly from the trunk once the gradle changes have been applied.
> >
> > Comments anyone?
> >
> > Thanks
> > Sharan
> >
> >
> > On 2016-06-30 07:25 (+0200), Jacopo Cappellato <
> > jacopo.cappell...@hotwaxsystems.com> wrote:
> > > 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 Christian.
> > > Your proposal makes sense but the problem is that we will not be able
> to
> > > release (14.12, 15.12 etc...) until we have removed all the jars from
> the
> > > distribution, and implementing this in the branches will require some
> > > layout changes that will bring instability: the releases will be
> delayed
> > > regardless and if we want to implement two different mechanisms for
> > > downloading the jars for 14.12 vs the trunk and 16.x etc... than the
> > > codebases will become rather different and more difficult to maintain;
> > and
> > > the extra effort will have to be backed up by the interested users. We
> > have
> > > to consider these aspects and do a reality check on resources before
> > moving
> > > in any direction.
> > >
> > > Jacopo
> > >
> >
>


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-30 Thread Ashish Vijaywargiya
+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 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. Unreleased they can contain the jar files and the
> special purpose components etc – but if we want to release them then we
> need to fix the jar file problem before it can be released.
>
> Christian mentions that people are using the unreleased branches, so by
> leaving them unreleased, we are actually giving our users something that
> can help them move from 13.07.
>
> So I suggest that we seriously consider leaving 14.12 and 15.12 as
> unreleased branches.
>
> For the next point – I think our next release should be the 16.x – so that
> means that we are not backporting any changes and can take a branch
> directly from the trunk once the gradle changes have been applied.
>
> Comments anyone?
>
> Thanks
> Sharan
>
>
> On 2016-06-30 07:25 (+0200), Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
> > 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 Christian.
> > Your proposal makes sense but the problem is that we will not be able to
> > release (14.12, 15.12 etc...) until we have removed all the jars from the
> > distribution, and implementing this in the branches will require some
> > layout changes that will bring instability: the releases will be delayed
> > regardless and if we want to implement two different mechanisms for
> > downloading the jars for 14.12 vs the trunk and 16.x etc... than the
> > codebases will become rather different and more difficult to maintain;
> and
> > the extra effort will have to be backed up by the interested users. We
> have
> > to consider these aspects and do a reality check on resources before
> moving
> > in any direction.
> >
> > Jacopo
> >
>


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-30 Thread Michael Brohl

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 branches.

The jar issue is only an issue if we want to convert the unreleased branches 
into a release. Unreleased they can contain the jar files and the special 
purpose components etc – but if we want to release them then we need to fix 
the jar file problem before it can be released.

Christian mentions that people are using the unreleased branches, so by leaving 
them unreleased, we are actually giving our users something that can help them 
move from 13.07.

So I suggest that we seriously consider leaving 14.12 and 15.12 as unreleased 
branches.

For the next point – I think our next release should be the 16.x – so that 
means that we are not backporting any changes and can take a branch directly 
from the trunk once the gradle changes have been applied.

Comments anyone?

Thanks
Sharan


On 2016-06-30 07:25 (+0200), Jacopo Cappellato 
 wrote:

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 Christian.
Your proposal makes sense but the problem is that we will not be able to
release (14.12, 15.12 etc...) until we have removed all the jars from the
distribution, and implementing this in the branches will require some
layout changes that will bring instability: the releases will be delayed
regardless and if we want to implement two different mechanisms for
downloading the jars for 14.12 vs the trunk and 16.x etc... than the
codebases will become rather different and more difficult to maintain; and
the extra effort will have to be backed up by the interested users. We have
to consider these aspects and do a reality check on resources before moving
in any direction.

Jacopo






smime.p7s
Description: S/MIME Cryptographic Signature


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-30 Thread Pranay Pandey
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 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 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. Unreleased they can contain the jar files and
> the
> > special purpose components etc – but if we want to release them then we
> > need to fix the jar file problem before it can be released.
> >
> > Christian mentions that people are using the unreleased branches, so by
> > leaving them unreleased, we are actually giving our users something that
> > can help them move from 13.07.
> >
> > So I suggest that we seriously consider leaving 14.12 and 15.12 as
> > unreleased branches.
> >
> > For the next point – I think our next release should be the 16.x – so
> that
> > means that we are not backporting any changes and can take a branch
> > directly from the trunk once the gradle changes have been applied.
> >
> > Comments anyone?
> >
> > Thanks
> > Sharan
> >
> >
> > On 2016-06-30 07:25 (+0200), Jacopo Cappellato <
> > jacopo.cappell...@hotwaxsystems.com> wrote:
> > > 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 Christian.
> > > Your proposal makes sense but the problem is that we will not be able
> to
> > > release (14.12, 15.12 etc...) until we have removed all the jars from
> the
> > > distribution, and implementing this in the branches will require some
> > > layout changes that will bring instability: the releases will be
> delayed
> > > regardless and if we want to implement two different mechanisms for
> > > downloading the jars for 14.12 vs the trunk and 16.x etc... than the
> > > codebases will become rather different and more difficult to maintain;
> > and
> > > the extra effort will have to be backed up by the interested users. We
> > have
> > > to consider these aspects and do a reality check on resources before
> > moving
> > > in any direction.
> > >
> > > Jacopo
> > >
> >
>


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-30 Thread Sharan Foga
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 ASAP so that our 
user community will have another release available. This will become our top 
priority.

I suggest that we close off the discussion now as I think we've had quite a 
detailed discussion and it looks like we have come to a consensus and resolved 
the issues. We can now take the discussion back to the dev list where we can 
talk about the timings, release roadmap and also the support timeframe for the 
unreleased branches.

Thanks
Sharan

On 2016-06-30 11:01 (+0200), Michael Brohl  wrote: 
> 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 branches.
> >
> > The jar issue is only an issue if we want to convert the unreleased 
> > branches into a release. Unreleased they can contain the jar files and the 
> > special purpose components etc – but if we want to release them then 
> > we need to fix the jar file problem before it can be released.
> >
> > Christian mentions that people are using the unreleased branches, so by 
> > leaving them unreleased, we are actually giving our users something that 
> > can help them move from 13.07.
> >
> > So I suggest that we seriously consider leaving 14.12 and 15.12 as 
> > unreleased branches.
> >
> > For the next point – I think our next release should be the 16.x 
> > – so that means that we are not backporting any changes and can take 
> > a branch directly from the trunk once the gradle changes have been applied.
> >
> > Comments anyone?
> >
> > Thanks
> > Sharan
> >
> >
> > On 2016-06-30 07:25 (+0200), Jacopo Cappellato 
> >  wrote:
> >> 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 Christian.
> >> Your proposal makes sense but the problem is that we will not be able to
> >> release (14.12, 15.12 etc...) until we have removed all the jars from the
> >> distribution, and implementing this in the branches will require some
> >> layout changes that will bring instability: the releases will be delayed
> >> regardless and if we want to implement two different mechanisms for
> >> downloading the jars for 14.12 vs the trunk and 16.x etc... than the
> >> codebases will become rather different and more difficult to maintain; and
> >> the extra effort will have to be backed up by the interested users. We have
> >> to consider these aspects and do a reality check on resources before moving
> >> in any direction.
> >>
> >> Jacopo
> >>
> 
> 
> 


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-06-30 Thread Pierre Smits
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 more what the shared conclusion of the PMC is
regarding this discussion, so that the entire community can anticipate to
what is coming in the near future, and what the PMC will take to the dev ml
for planning purposes regarding the short term actions.

Best regards,


Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Thu, Jun 30, 2016 at 2:26 PM, Sharan Foga  wrote:

> 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 ASAP so
> that our user community will have another release available. This will
> become our top priority.
>
> I suggest that we close off the discussion now as I think we've had quite
> a detailed discussion and it looks like we have come to a consensus and
> resolved the issues. We can now take the discussion back to the dev list
> where we can talk about the timings, release roadmap and also the support
> timeframe for the unreleased branches.
>
> Thanks
> Sharan
>
> On 2016-06-30 11:01 (+0200), Michael Brohl 
> wrote:
> > 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 branches.
> > >
> > > The jar issue is only an issue if we want to convert the unreleased
> branches into a release. Unreleased they can contain the jar files and the
> special purpose components etc – but if we want to release them then we
> need to fix the jar file problem before it can be released.
> > >
> > > Christian mentions that people are using the unreleased branches, so
> by leaving them unreleased, we are actually giving our users something that
> can help them move from 13.07.
> > >
> > > So I suggest that we seriously consider leaving 14.12 and 15.12 as
> unreleased branches.
> > >
> > > For the next point – I think our next release should be the 16.x –
> so that means that we are not backporting any changes and can take a branch
> directly from the trunk once the gradle changes have been applied.
> > >
> > > Comments anyone?
> > >
> > > Thanks
> > > Sharan
> > >
> > >
> > > On 2016-06-30 07:25 (+0200), Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
> > >> 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 Christian.
> > >> Your proposal makes sense but the problem is that we will not be able
> to
> > >> release (14.12, 15.12 etc...) until we have removed all the jars from
> the
> > >> distribution, and implementing this in the branches will require some
> > >> layout changes that will bring instability: the releases will be
> delayed
> > >> regardless and if we want to implement two different mechanisms for
> > >> downloading the jars for 14.12 vs the trunk and 16.x etc... than the
> > >> codebases will become rather different and more difficult to
> maintain; and
> > >> the extra effort will have to be backed up by the interested users.
> We have
> > >> to consider these aspects and do a reality check on resources before
> moving
> > >> in any direction.
> > >>
> > >> Jacopo
> > >>
> >
> >
> >
>


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-07-01 Thread Sharan Foga
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 feedback that any 
conclusions are drawn or decisions taken . 

My understanding is that there was general consensus for the following:

- There would be no more releases from 13.07 so the current release that is out 
would be the last one in that series

- We would not backport any of the gradle changes into the 14.12. or 15.12 
branches because it would cause instability

- We would leave 14.12 and 15.12 as unreleased branches as they are now (and 
not make them into releases as to do that we would need to remove all the jar 
files and this would create instability). 

- We would focus on implementing the gradle changes into the trunk and then 
creating and stabilising a 16.x release ASAP

- The benefits for our community are that developers and service providers will 
still have access to the complete codebase for 14.12 and 15.12 including the 
special purpose components to be able to support their client base.

I suggested taking the discussion to the development list so that we can talk 
in more detail about the release planning and also the duration of support the 
unreleased branches. This again, will be a community discussion and decision. 
Once we have these details we can communicate them to our user community.

This was my understanding, so if anyone has a another interpretation or 
understanding then please feel free to comment.

Thanks
Sharan

On 2016-06-30 15:40 (+0200), Pierre Smits  wrote: 
> 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 more what the shared conclusion of the PMC is
> regarding this discussion, so that the entire community can anticipate to
> what is coming in the near future, and what the PMC will take to the dev ml
> for planning purposes regarding the short term actions.
> 
> Best regards,
> 
> 
> Pierre Smits
> 
> ORRTIZ.COM 
> OFBiz based solutions & services
> 
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
> 
> On Thu, Jun 30, 2016 at 2:26 PM, Sharan Foga  wrote:
> 
> > 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 ASAP so
> > that our user community will have another release available. This will
> > become our top priority.
> >
> > I suggest that we close off the discussion now as I think we've had quite
> > a detailed discussion and it looks like we have come to a consensus and
> > resolved the issues. We can now take the discussion back to the dev list
> > where we can talk about the timings, release roadmap and also the support
> > timeframe for the unreleased branches.
> >
> > Thanks
> > Sharan
> >
> > On 2016-06-30 11:01 (+0200), Michael Brohl 
> > wrote:
> > > 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 branches.
> > > >
> > > > The jar issue is only an issue if we want to convert the unreleased
> > branches into a release. Unreleased they can contain the jar files and the
> > special purpose components etc – but if we want to release them then 
> > we
> > need to fix the jar file problem before it can be released.
> > > >
> > > > Christian mentions that people are using the unreleased branches, so
> > by leaving them unreleased, we are actually giving our users something that
> > can help them move from 13.07.
> > > >
> > > > So I suggest that we seriously consider leaving 14.12 and 15.12 as
> > unreleased branches.
> > > >
> > > > For the next point – I think our next release should be the 16.x 
> > > > –
> > so that means that we are not backporting any changes and can take a branch
> > directly from the trunk once the gradle changes have been applied.
> > > >
> > > > Comments anyone?
> > > >
> > > > Thanks
> > > > Sharan
> > > >
> > > >
> > > > On 2016-06-30 07:25 (+0200), Jacopo Cappellato <
> > jacopo.cappell...@hotwaxsystems.com> wrote:
> > > >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > > >> christian.geis...@isu-gmbh.de> wrote:
> > > >>
> > > >>> ...
> >

Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-07-01 Thread Charl Bouwer
Hi all

Where does it leave a new user that is planning to become a contributor. I
am past the R&D 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 already able to setup eclipse with debugging enabled and have both
the trunk and 13.07 SVN repositories. I am busy doing the same with
Intellij/GIT setup, my preferred IDE environment. I am planning to use the
POC to customise for my region, including the initial seed data. Which in
turn will lead to me working on the multi tenancy aspect.

Should I continue with 13.07 as base with the intention to have a
production server in the next say 3-6 months.
Any suggestions on how I should proceed from here?

Sorry I only subscribed to the dev-list today

Thanks
Charl


On Fri, Jul 1, 2016 at 9:01 AM, Sharan Foga  wrote:

> 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 feedback that any
> conclusions are drawn or decisions taken .
>
> My understanding is that there was general consensus for the following:
>
> - There would be no more releases from 13.07 so the current release that
> is out would be the last one in that series
>
> - We would not backport any of the gradle changes into the 14.12. or 15.12
> branches because it would cause instability
>
> - We would leave 14.12 and 15.12 as unreleased branches as they are now
> (and not make them into releases as to do that we would need to remove all
> the jar files and this would create instability).
>
> - We would focus on implementing the gradle changes into the trunk and
> then creating and stabilising a 16.x release ASAP
>
> - The benefits for our community are that developers and service providers
> will still have access to the complete codebase for 14.12 and 15.12
> including the special purpose components to be able to support their client
> base.
>
> I suggested taking the discussion to the development list so that we can
> talk in more detail about the release planning and also the duration of
> support the unreleased branches. This again, will be a community discussion
> and decision. Once we have these details we can communicate them to our
> user community.
>
> This was my understanding, so if anyone has a another interpretation or
> understanding then please feel free to comment.
>
> Thanks
> Sharan
>
> On 2016-06-30 15:40 (+0200), Pierre Smits  wrote:
> > 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 more what the shared conclusion of the PMC is
> > regarding this discussion, so that the entire community can anticipate to
> > what is coming in the near future, and what the PMC will take to the dev
> ml
> > for planning purposes regarding the short term actions.
> >
> > Best regards,
> >
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Thu, Jun 30, 2016 at 2:26 PM, Sharan Foga 
> wrote:
> >
> > > 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 ASAP so
> > > that our user community will have another release available. This will
> > > become our top priority.
> > >
> > > I suggest that we close off the discussion now as I think we've had
> quite
> > > a detailed discussion and it looks like we have come to a consensus and
> > > resolved the issues. We can now take the discussion back to the dev
> list
> > > where we can talk about the timings, release roadmap and also the
> support
> > > timeframe for the unreleased branches.
> > >
> > > Thanks
> > > Sharan
> > >
> > > On 2016-06-30 11:01 (+0200), Michael Brohl 
> > > wrote:
> > > > 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 branches.
> > > > >
> > > > > The jar issue is only an issue if we want to convert the unreleased
> > > branches into a release. Unre

Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-07-02 Thread Sharan Foga
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 changes. I also think that a lot of developers base 
their work on our branches rather than the release itself. 

The 14.12 branch was created in December 2014 and contains new features not 
present in 13.07. We have backported bug fixes to it, so it has been maturing 
and stabilising for over 18 months and would have been our next release. Also 
recent OFBiz fork announced this mailing list is based on our 14.12 branch.

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 think it is all about risk. Depending on what you want to achieve with your 
POC, then I suspect that you could still possibly go ahead using 14.12 instead 
of 13.07 if you wanted to, so perhaps take a look at the differences between 
14.12 and 13.07 to see if it affects what you were wanting to do.

Thanks
Sharan

On 2016-07-01 15:15 (+0200), Charl Bouwer  wrote: 
> Hi all
> 
> Where does it leave a new user that is planning to become a contributor. I
> am past the R&D 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 already able to setup eclipse with debugging enabled and have both
> the trunk and 13.07 SVN repositories. I am busy doing the same with
> Intellij/GIT setup, my preferred IDE environment. I am planning to use the
> POC to customise for my region, including the initial seed data. Which in
> turn will lead to me working on the multi tenancy aspect.
> 
> Should I continue with 13.07 as base with the intention to have a
> production server in the next say 3-6 months.
> Any suggestions on how I should proceed from here?
> 
> Sorry I only subscribed to the dev-list today
> 
> Thanks
> Charl
> 
> 
> On Fri, Jul 1, 2016 at 9:01 AM, Sharan Foga  wrote:
> 
> > 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 feedback that any
> > conclusions are drawn or decisions taken .
> >
> > My understanding is that there was general consensus for the following:
> >
> > - There would be no more releases from 13.07 so the current release that
> > is out would be the last one in that series
> >
> > - We would not backport any of the gradle changes into the 14.12. or 15.12
> > branches because it would cause instability
> >
> > - We would leave 14.12 and 15.12 as unreleased branches as they are now
> > (and not make them into releases as to do that we would need to remove all
> > the jar files and this would create instability).
> >
> > - We would focus on implementing the gradle changes into the trunk and
> > then creating and stabilising a 16.x release ASAP
> >
> > - The benefits for our community are that developers and service providers
> > will still have access to the complete codebase for 14.12 and 15.12
> > including the special purpose components to be able to support their client
> > base.
> >
> > I suggested taking the discussion to the development list so that we can
> > talk in more detail about the release planning and also the duration of
> > support the unreleased branches. This again, will be a community discussion
> > and decision. Once we have these details we can communicate them to our
> > user community.
> >
> > This was my understanding, so if anyone has a another interpretation or
> > understanding then please feel free to comment.
> >
> > Thanks
> > Sharan
> >
> > On 2016-06-30 15:40 (+0200), Pierre Smits  wrote:
> > > 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 more what the shared conclusion of the PMC is
> > > regarding this discussion, so that the entire community can anticipate to
> > > what is coming in the near future, and what the PMC will take to the dev
> > ml
> > > for planning purposes regarding the short term actions.
> > >
> > > Best regards,
> > >
> > >
> > > Pierre Smits
> > >
> > > ORRTIZ.COM 
> > > OFBiz based solutions & services
> > >
> > > OFBiz Extensions Marketplace
> > > http://oem.ofbizci.net/oci-2/
> > >
> > > On Thu, Jun 30, 2016 at 2:26 PM, Sharan Foga 
> > w

Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-07-02 Thread Pierre Smits
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 several cases - also backported
improvements from trunk into release branches.

Sharan is correct regarding risk!
Without a shared agreement - on conclusions derived from discussion threads
- by the contributors with binding powers (PMC Members), any privileged
contributor (those contributors with commit privileges) can do whatever
they want in any of the branches.
They can continue to add bug fixes to branches. Also, any contributor can
continue to register issues regarding specific branches/releases and
provide patches to fix those.
This helps adopters to both minimise risk as well as stay connected to the
project: They can use JIRA as a risk reporting and monitoring mechanism and
the projects code repos (ASF SVN/Git, Github) as code source for those
aspects of their OFBiz implementation that they don't want to have control
over, but leave it to their benevolent privileged contributors.

I trust this helps.

Best regards,



Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Sat, Jul 2, 2016 at 11:28 AM, Sharan Foga  wrote:

> 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 changes. I also think that a lot of
> developers base their work on our branches rather than the release itself.
>
> The 14.12 branch was created in December 2014 and contains new features
> not present in 13.07. We have backported bug fixes to it, so it has been
> maturing and stabilising for over 18 months and would have been our next
> release. Also recent OFBiz fork announced this mailing list is based on our
> 14.12 branch.
>
> 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 think it is all about risk. Depending on what you want to achieve with
> your POC, then I suspect that you could still possibly go ahead using 14.12
> instead of 13.07 if you wanted to, so perhaps take a look at the
> differences between 14.12 and 13.07 to see if it affects what you were
> wanting to do.
>
> Thanks
> Sharan
>
> On 2016-07-01 15:15 (+0200), Charl Bouwer  wrote:
> > Hi all
> >
> > Where does it leave a new user that is planning to become a contributor.
> I
> > am past the R&D 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 already able to setup eclipse with debugging enabled and have both
> > the trunk and 13.07 SVN repositories. I am busy doing the same with
> > Intellij/GIT setup, my preferred IDE environment. I am planning to use
> the
> > POC to customise for my region, including the initial seed data. Which in
> > turn will lead to me working on the multi tenancy aspect.
> >
> > Should I continue with 13.07 as base with the intention to have a
> > production server in the next say 3-6 months.
> > Any suggestions on how I should proceed from here?
> >
> > Sorry I only subscribed to the dev-list today
> >
> > Thanks
> > Charl
> >
> >
> > On Fri, Jul 1, 2016 at 9:01 AM, Sharan Foga 
> wrote:
> >
> > > 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 feedback that any
> > > conclusions are drawn or decisions taken .
> > >
> > > My understanding is that there was general consensus for the following:
> > >
> > > - There would be no more releases from 13.07 so the current release
> that
> > > is out would be the last one in that series
> > >
> > > - We would not backport any of the gradle changes into the 14.12. or
> 15.12
> > > branches because it would cause instability
> > >
> > > - We would leave 14.12 and 15.12 as unreleased branches as they are now
> > > (and not make them into releases as to do that we would need to remove
> all
> > > the jar files and this would create instability).
> > >
> > > - We would focus on implementing the gradle changes into the trunk and
> > > then creating and stabilising a 16.x release ASAP
> > >
> > > - The benefits for our community are that developers and service
> providers
> > > will still have access to

Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-07-02 Thread Jacques Le Roux

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 experience the stability is not much an issue, because OFBiz is mature and the community is 
responsive. You will though have to cross the change from Ant to Gradle https://issues.apache.org/jira/browse/OFBIZ-7534.  From my recent and limited 
experience, it's so far not a biggie.


Personally I'd base my work on the trunk and when the R16 branch will be cut I'd switch to it waiting for the released package to recommend to 
clients. We want and are engaged to release the R16 package ASAP so it's not a big risk.


This is my personal opinion and does not engage the PMC

Cheers

Jacques


Le 01/07/2016 à 15:15, Charl Bouwer a écrit :

Hi all

Where does it leave a new user that is planning to become a contributor. I
am past the R&D 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 already able to setup eclipse with debugging enabled and have both
the trunk and 13.07 SVN repositories. I am busy doing the same with
Intellij/GIT setup, my preferred IDE environment. I am planning to use the
POC to customise for my region, including the initial seed data. Which in
turn will lead to me working on the multi tenancy aspect.

Should I continue with 13.07 as base with the intention to have a
production server in the next say 3-6 months.
Any suggestions on how I should proceed from here?

Sorry I only subscribed to the dev-list today

Thanks
Charl


On Fri, Jul 1, 2016 at 9:01 AM, Sharan Foga  wrote:


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 feedback that any
conclusions are drawn or decisions taken .

My understanding is that there was general consensus for the following:

- There would be no more releases from 13.07 so the current release that
is out would be the last one in that series

- We would not backport any of the gradle changes into the 14.12. or 15.12
branches because it would cause instability

- We would leave 14.12 and 15.12 as unreleased branches as they are now
(and not make them into releases as to do that we would need to remove all
the jar files and this would create instability).

- We would focus on implementing the gradle changes into the trunk and
then creating and stabilising a 16.x release ASAP

- The benefits for our community are that developers and service providers
will still have access to the complete codebase for 14.12 and 15.12
including the special purpose components to be able to support their client
base.

I suggested taking the discussion to the development list so that we can
talk in more detail about the release planning and also the duration of
support the unreleased branches. This again, will be a community discussion
and decision. Once we have these details we can communicate them to our
user community.

This was my understanding, so if anyone has a another interpretation or
understanding then please feel free to comment.

Thanks
Sharan

On 2016-06-30 15:40 (+0200), Pierre Smits  wrote:

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 more what the shared conclusion of the PMC is
regarding this discussion, so that the entire community can anticipate to
what is coming in the near future, and what the PMC will take to the dev

ml

for planning purposes regarding the short term actions.

Best regards,


Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Thu, Jun 30, 2016 at 2:26 PM, Sharan Foga 

wrote:

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 ASAP so
that our user community will have another release available. This will
become our top priority.

I suggest that we close off the discussion now as I think we've had

quite

a detailed discussion and it looks like we have come to a consensus and
resolved the issues. We can now take the discussion back to the dev

list

where we can talk about the timings, release ro

Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-07-02 Thread Jacques Le Roux

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 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 several cases - also backported
improvements from trunk into release branches.

Sharan is correct regarding risk!
Without a shared agreement - on conclusions derived from discussion threads
- by the contributors with binding powers (PMC Members), any privileged
contributor (those contributors with commit privileges) can do whatever
they want in any of the branches.
They can continue to add bug fixes to branches. Also, any contributor can
continue to register issues regarding specific branches/releases and
provide patches to fix those.
This helps adopters to both minimise risk as well as stay connected to the
project: They can use JIRA as a risk reporting and monitoring mechanism and
the projects code repos (ASF SVN/Git, Github) as code source for those
aspects of their OFBiz implementation that they don't want to have control
over, but leave it to their benevolent privileged contributors.

I trust this helps.

Best regards,



Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Sat, Jul 2, 2016 at 11:28 AM, Sharan Foga  wrote:


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 changes. I also think that a lot of
developers base their work on our branches rather than the release itself.

The 14.12 branch was created in December 2014 and contains new features
not present in 13.07. We have backported bug fixes to it, so it has been
maturing and stabilising for over 18 months and would have been our next
release. Also recent OFBiz fork announced this mailing list is based on our
14.12 branch.

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 think it is all about risk. Depending on what you want to achieve with
your POC, then I suspect that you could still possibly go ahead using 14.12
instead of 13.07 if you wanted to, so perhaps take a look at the
differences between 14.12 and 13.07 to see if it affects what you were
wanting to do.

Thanks
Sharan

On 2016-07-01 15:15 (+0200), Charl Bouwer  wrote:

Hi all

Where does it leave a new user that is planning to become a contributor.

I

am past the R&D 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 already able to setup eclipse with debugging enabled and have both
the trunk and 13.07 SVN repositories. I am busy doing the same with
Intellij/GIT setup, my preferred IDE environment. I am planning to use

the

POC to customise for my region, including the initial seed data. Which in
turn will lead to me working on the multi tenancy aspect.

Should I continue with 13.07 as base with the intention to have a
production server in the next say 3-6 months.
Any suggestions on how I should proceed from here?

Sorry I only subscribed to the dev-list today

Thanks
Charl


On Fri, Jul 1, 2016 at 9:01 AM, Sharan Foga 

wrote:

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 feedback that any
conclusions are drawn or decisions taken .

My understanding is that there was general consensus for the following:

- There would be no more releases from 13.07 so the current release

that

is out would be the last one in that series

- We would not backport any of the gradle changes into the 14.12. or

15.12

branches because it would cause instability

- We would leave 14.12 and 15.12 as unreleased branches as they are now
(and not make them into releases as to do that we would need to remove

all

the jar files and this would create instability).

- We would focus on implementing the gradle changes into the trunk and
then creating and stabilising a 16.x release ASAP

- The benefits for our community are that developers and service

providers

will still have access to the complete codebase for 14.12 and 15.12
including the special purpose components to be able to support their

client

base.

Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-07-02 Thread Jacques Le Roux

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



Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-07-02 Thread Sharan Foga
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 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
> 
> 


Re: [DISCUSSION] Anticipate the end of life of the 13.07 branch and backport some non-bug related changes to the 14.12 and 15.12 branches

2016-07-02 Thread Jacques Le Roux

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 2016-07-02 15:04 (+0200), Jacques Le Roux  
wrote:

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