[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

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

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

[Jacques Le Roux <ja...@les7arts.com>]

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

[Taher Alkhateeb <sl...@gmail.com>]

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

[Julien NICOLAS <ju...@nereide.fr>]

+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

[Jacques Le Roux <ja...@les7arts.com>]

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

[Jacques Le Roux <ja...@les7arts.com>]

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

[Paul Piper <pp...@ilscipio.com>]

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

[Jacques Le Roux <ja...@les7arts.com>]

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

[Divesh Dutta <di...@hotwaxsystems.com>]

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 <pp...@ilscipio.com> 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

[Paul Piper <pp...@ilscipio.com>]

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

[Jacques Le Roux <ja...@les7arts.com>]

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 <http://www.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 <tt...@infotinuum.com>
> 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.cappellato@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

[Pierre Smits <pi...@gmail.com>]

+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 <http://www.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 <tt...@infotinuum.com>
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.cappellato@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

[Taher Alkhateeb <sl...@gmail.com>]

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" <sl...@gmail.com>
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" <sh...@gmail.com> 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 <tt...@infotinuum.com> 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.cappellato@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

[Taher Alkhateeb <sl...@gmail.com>]

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" <sh...@gmail.com> 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 <tt...@infotinuum.com> 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.cappellato@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

[Sharan Foga <sh...@gmail.com>]

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 <tt...@infotinuum.com> 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 <ja...@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

[Todd Thorner <tt...@infotinuum.com>]

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 <ja...@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

[Sharan Foga <sh...@gmail.com>]

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 <ja...@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

[Jacques Le Roux <ja...@les7arts.com>]

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

[Sharan Foga <sh...@gmail.com>]

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) \u2013 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 <ch...@isu-gmbh.de> 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

[Ashish Vijaywargiya <as...@hotwaxsystems.com>]

+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 <slidingfilaments@gmail.com
> 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" <sh...@apache.org> 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.cappellato@hotwaxsystems.com> wrote:
> > > On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > > christian.geisert@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

[Taher Alkhateeb <sl...@gmail.com>]

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" <sh...@apache.org> 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.cappellato@hotwaxsystems.com> wrote:
> > On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > christian.geisert@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

[Jacques Le Roux <ja...@les7arts.com>]

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 <sh...@gmail.com> wrote:
>
>> Hi Charl
>>
>> I'm not a developer \u2013 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 <za...@gmail.com> 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 <sh...@gmail.com>
>> 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 \u201cthe
>> shared
>>>> conclusion of the PMC\u201d. 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 <pi...@gmail.com>
>> 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 <sh...@gmail.com>
>>>> 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 <
>> michael.brohl@ecomify.de>
>>>>>> 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
>>>>>> �\u20ac\u201c 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 �\u20ac\u201c 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 �\u20ac\u201c I think our next release should be the
>> 16.x
>>>> �\u20ac\u201c
>>>>>> 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.cappellato@hotwaxsystems.com> wrote:
>>>>>>>>> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
>>>>>>>>> christian.geisert@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

[Jacques Le Roux <ja...@les7arts.com>]

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 <ja...@les7arts.com> wrote:
>> Le 02/07/2016 \ufffd 11:55, Pierre Smits a \ufffdcrit :
>>> 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

[Sharan Foga <sh...@gmail.com>]

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 <ja...@les7arts.com> wrote: 
> Le 02/07/2016 \ufffd 11:55, Pierre Smits a \ufffdcrit :
> > 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

[Jacques Le Roux <ja...@les7arts.com>]

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

[Pierre Smits <pi...@gmail.com>]

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 <sh...@gmail.com> 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 <za...@gmail.com> 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 <sh...@gmail.com>
> 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 <pi...@gmail.com>
> 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 <sh...@gmail.com>
> > > 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 <
> michael.brohl@ecomify.de>
> > > > > 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.cappellato@hotwaxsystems.com> wrote:
> > > > > > >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > > > > > >> christian.geisert@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

[Sharan Foga <sh...@gmail.com>]

Hi Charl

I'm not a developer \u2013 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 <za...@gmail.com> 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 <sh...@gmail.com> 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 \u201cthe shared
> > conclusion of the PMC\u201d. 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 <pi...@gmail.com> 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 <sh...@gmail.com>
> > 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 <mi...@ecomify.de>
> > > > 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
> > > > â\u20ac\u201c 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 â\u20ac\u201c 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 â\u20ac\u201c I think our next release should be the 16.x
> > â\u20ac\u201c
> > > > 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.cappellato@hotwaxsystems.com> wrote:
> > > > > >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > > > > >> christian.geisert@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

[Jacques Le Roux <ja...@les7arts.com>]

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 <sh...@gmail.com> 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 \u201cthe shared
>> conclusion of the PMC\u201d. 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 <pi...@gmail.com> 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 <sh...@gmail.com>
>> 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 <mi...@ecomify.de>
>>>> 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
>>>> �\u20ac\u201c 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 �\u20ac\u201c 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 �\u20ac\u201c I think our next release should be the 16.x
>> �\u20ac\u201c
>>>> 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.cappellato@hotwaxsystems.com> wrote:
>>>>>>> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
>>>>>>> christian.geisert@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

[Charl Bouwer <za...@gmail.com>]

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 <sh...@gmail.com> 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 <pi...@gmail.com> 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 <sh...@gmail.com>
> 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 <mi...@ecomify.de>
> > > 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.cappellato@hotwaxsystems.com> wrote:
> > > > >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > > > >> christian.geisert@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

[Sharan Foga <sh...@gmail.com>]

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 \u201cthe shared conclusion of the PMC\u201d. 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 <pi...@gmail.com> 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 <sh...@gmail.com> 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 <mi...@ecomify.de>
> > 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
> > â\u20ac\u201c 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 â\u20ac\u201c 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 â\u20ac\u201c I think our next release should be the 16.x â\u20ac\u201c
> > 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.cappellato@hotwaxsystems.com> wrote:
> > > >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > > >> christian.geisert@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

[Pierre Smits <pi...@gmail.com>]

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 <sh...@gmail.com> 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 <mi...@ecomify.de>
> 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.cappellato@hotwaxsystems.com> wrote:
> > >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > >> christian.geisert@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

[Sharan Foga <sh...@gmail.com>]

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 <mi...@ecomify.de> 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 â\u20ac\u201c 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 â\u20ac\u201c 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 â\u20ac\u201c I think our next release should be the 16.x â\u20ac\u201c 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 <ja...@hotwaxsystems.com> wrote:
> >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> >> christian.geisert@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

[Michael Brohl <mi...@ecomify.de>]

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 <ja...@hotwaxsystems.com> wrote:
>> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
>> christian.geisert@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

[Pranay Pandey <pr...@hotwaxsystems.com>]

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.vijaywargiya@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 <sh...@apache.org> 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.cappellato@hotwaxsystems.com> wrote:
> > > On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > > christian.geisert@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

[Ashish Vijaywargiya <as...@hotwaxsystems.com>]

+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 <sh...@apache.org> 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.cappellato@hotwaxsystems.com> wrote:
> > On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > christian.geisert@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

[Sharan Foga <sh...@apache.org>]

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 \u2013 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 \u2013 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 \u2013 I think our next release should be the 16.x \u2013 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 <ja...@hotwaxsystems.com> wrote: 
> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> christian.geisert@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

[Jacopo Cappellato <ja...@hotwaxsystems.com>]

On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
christian.geisert@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

[Michael Brohl <mi...@ecomify.de>]

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

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

[gil portenseigne <gi...@nereide.fr>]

+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

[Christian Geisert <ch...@isu-gmbh.de>]

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

[Deepak Dixit <de...@hotwaxsystems.com>]

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.vijaywargiya@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.cappellato@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

[Ashish Vijaywargiya <as...@hotwaxsystems.com>]

+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.cappellato@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

[Pranay Pandey <pr...@hotwaxsystems.com>]

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.cappellato@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
>