[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

[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

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

[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

[Michael Brohl-3]

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

[Jacopo Cappellato-5]

On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
[hidden email]> 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

[Sharan-F]

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 <[hidden email]> 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
> >
>
>

[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 <[hidden email]> wrote:

> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> [hidden email]> 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
>

[taher]

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" <[hidden email]> 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 <
> [hidden email]> wrote:
> > On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > [hidden email]> 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
> >
>

[Ashish Vijaywargiya-4]

+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 <[hidden email]
> 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" <[hidden email]> 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 <
> > [hidden email]> wrote:
> > > On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > > [hidden email]> 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
> > >
> >
>

[Ashish Vijaywargiya-4]

+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 <[hidden email]> 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 <
> [hidden email]> wrote:
> > On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > [hidden email]> 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
> >
>

[Michael Brohl-3]

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 <[hidden email]> wrote:
>> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
>> [hidden email]> 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
>>

[Pranay Pandey-3]

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 <
[hidden email]> 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 <[hidden email]> 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 <
> > [hidden email]> wrote:
> > > On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > > [hidden email]> 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
> > >
> >
>

[Sharan-F]

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 <[hidden email]> 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 <[hidden email]> wrote:
> >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> >> [hidden email]> 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
> >>
>
>
>

[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 <http://www.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 <[hidden email]> 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 <[hidden email]>
> 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 <
> [hidden email]> wrote:
> > >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > >> [hidden email]> 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
> > >>
> >
> >
> >
>

[Sharan-F]

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 <[hidden email]> 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 <http://www.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 <[hidden email]> 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 <[hidden email]>
> > 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 <
> > [hidden email]> wrote:
> > > >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > > >> [hidden email]> 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
> > > >>
> > >
> > >
> > >
> >
>

[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 <[hidden email]> 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 <[hidden email]> 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 <http://www.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 <[hidden email]>
> 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 <[hidden email]>
> > > 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 <
> > > [hidden email]> wrote:
> > > > >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > > > >> [hidden email]> 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
> > > > >>
> > > >
> > > >
> > > >
> > >
> >
>

[Sharan-F]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <http://www.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 <[hidden email]>
> > 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 <[hidden email]>
> > > > 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 <
> > > > [hidden email]> wrote:
> > > > > >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > > > > >> [hidden email]> 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
> > > > > >>
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

[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 <http://www.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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> 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 <http://www.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 <[hidden email]>
> > > 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 <
> [hidden email]>
> > > > > 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 <
> > > > > [hidden email]> wrote:
> > > > > > >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > > > > > >> [hidden email]> 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
> > > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[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 <[hidden email]> 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 <[hidden email]> 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 <http://www.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 <[hidden email]>
>> 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 <[hidden email]>
>>>> 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 <
>>>> [hidden email]> wrote:
>>>>>>> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
>>>>>>> [hidden email]> 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
>>>>>>>
>>>>>
>>>>>

[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 <http://www.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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]>
>> 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 <http://www.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 <[hidden email]>
>>>> 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 <
>> [hidden email]>
>>>>>> 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 <
>>>>>> [hidden email]> wrote:
>>>>>>>>> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
>>>>>>>>> [hidden email]> 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
>>>>>>>>>
>>>>>>>
>>>>>>>