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]

It seems to me that Sharan is jumping the fence a bit to soon. Multiple
suggestions have gathered support.
This makes any 'this solution', without repeating what that solution is ,
multi-interpretable and would not only continue the discussion. But also
the confusion.

I suggest to repeat once more what the shared conclusion of the PMC is
regarding this discussion, so that the entire community can anticipate to
what is coming in the near future, and what the PMC will take to the dev ml
for planning purposes regarding the short term actions.

Best regards,


Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

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

> Hi Everyone
>
> Thanks very much for the feedback. I'm glad that this solution will
> resolve our current problems without taking away any functionality from the
> service providers or developers that are using the unreleased branches.
>
> Our next step will be to create and stabilise the 16.x release ASAP so
> that our user community will have another release available. This will
> become our top priority.
>
> I suggest that we close off the discussion now as I think we've had quite
> a detailed discussion and it looks like we have come to a consensus and
> resolved the issues. We can now take the discussion back to the dev list
> where we can talk about the timings, release roadmap and also the support
> timeframe for the unreleased branches.
>
> Thanks
> Sharan
>
> On 2016-06-30 11:01 (+0200), Michael Brohl 
> wrote:
> > Great idea, +1
> >
> > Michael Brohl
> > ecomify GmbH
> > www.ecomify.de
> >
> >
> > Am 30.06.16 um 09:05 schrieb Sharan Foga:
> > > Thanks for the response -Jacopo. (You posted a minute before I did!)
> > >
> > > Anyway I think that I might have an idea that could solve our problem
> – let's just leave 14.12 and 15.12 as unreleased branches.
> > >
> > > The jar issue is only an issue if we want to convert the unreleased
> branches into a release. Unreleased they can contain the jar files and the
> special purpose components etc – but if we want to release them then we
> need to fix the jar file problem before it can be released.
> > >
> > > Christian mentions that people are using the unreleased branches, so
> by leaving them unreleased, we are actually giving our users something that
> can help them move from 13.07.
> > >
> > > So I suggest that we seriously consider leaving 14.12 and 15.12 as
> unreleased branches.
> > >
> > > For the next point – I think our next release should be the 16.x –
> so that means that we are not backporting any changes and can take a branch
> directly from the trunk once the gradle changes have been applied.
> > >
> > > Comments anyone?
> > >
> > > Thanks
> > > Sharan
> > >
> > >
> > > On 2016-06-30 07:25 (+0200), Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
> > >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > >> christian.geis...@isu-gmbh.de> wrote:
> > >>
> > >>> ...
> > >>> My proposal is to release 14.12 ASAP, after that dropping 13.07 and
> then
> > >>> trying to do a release 16.x with Gradle. And a release of 15.12in
> > >>> between wouldn't be bad either ;)
> > >>>
> > >>>
> > >> Thank you Christian.
> > >> Your proposal makes sense but the problem is that we will not be able
> to
> > >> release (14.12, 15.12 etc...) until we have removed all the jars from
> the
> > >> distribution, and implementing this in the branches will require some
> > >> layout changes that will bring instability: the releases will be
> delayed
> > >> regardless and if we want to implement two different mechanisms for
> > >> downloading the jars for 14.12 vs the trunk and 16.x etc... than the
> > >> codebases will become rather different and more difficult to
> maintain; and
> > >> the extra effort will have to be backed up by the interested users.
> We have
> > >> to consider these aspects and do a reality check on resources before
> moving
> > >> in any direction.
> > >>
> > >> Jacopo
> > >>
> >
> >
> >
>

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

[Sharan Foga]

Hi Everyone

Thanks very much for the feedback. I'm glad that this solution will resolve our 
current problems without taking away any functionality from the service 
providers or developers that are using the unreleased branches.  

Our next step will be to create and stabilise the 16.x release ASAP so that our 
user community will have another release available. This will become our top 
priority.

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

Thanks
Sharan

On 2016-06-30 11:01 (+0200), Michael Brohl  wrote: 
> Great idea, +1
> 
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
> 
> 
> Am 30.06.16 um 09:05 schrieb Sharan Foga:
> > Thanks for the response -Jacopo. (You posted a minute before I did!)
> >
> > Anyway I think that I might have an idea that could solve our problem 
> > – let's just leave 14.12 and 15.12 as unreleased branches.
> >
> > The jar issue is only an issue if we want to convert the unreleased 
> > branches into a release. Unreleased they can contain the jar files and the 
> > special purpose components etc – but if we want to release them then 
> > we need to fix the jar file problem before it can be released.
> >
> > Christian mentions that people are using the unreleased branches, so by 
> > leaving them unreleased, we are actually giving our users something that 
> > can help them move from 13.07.
> >
> > So I suggest that we seriously consider leaving 14.12 and 15.12 as 
> > unreleased branches.
> >
> > For the next point – I think our next release should be the 16.x 
> > – so that means that we are not backporting any changes and can take 
> > a branch directly from the trunk once the gradle changes have been applied.
> >
> > Comments anyone?
> >
> > Thanks
> > Sharan
> >
> >
> > On 2016-06-30 07:25 (+0200), Jacopo Cappellato 
> >  wrote:
> >> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> >> christian.geis...@isu-gmbh.de> wrote:
> >>
> >>> ...
> >>> My proposal is to release 14.12 ASAP, after that dropping 13.07 and then
> >>> trying to do a release 16.x with Gradle. And a release of 15.12in
> >>> between wouldn't be bad either ;)
> >>>
> >>>
> >> Thank you Christian.
> >> Your proposal makes sense but the problem is that we will not be able to
> >> release (14.12, 15.12 etc...) until we have removed all the jars from the
> >> distribution, and implementing this in the branches will require some
> >> layout changes that will bring instability: the releases will be delayed
> >> regardless and if we want to implement two different mechanisms for
> >> downloading the jars for 14.12 vs the trunk and 16.x etc... than the
> >> codebases will become rather different and more difficult to maintain; and
> >> the extra effort will have to be backed up by the interested users. We have
> >> to consider these aspects and do a reality check on resources before moving
> >> in any direction.
> >>
> >> Jacopo
> >>
> 
> 
> 

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

[Pranay Pandey]

Liked the idea Sharan +1

Best regards,

Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/

On Thu, Jun 30, 2016 at 2:30 PM, Ashish Vijaywargiya <
ashish.vijaywarg...@hotwaxsystems.com> wrote:

> +1, Very good idea. Thanks so much Sharan!
>
> Kind Regards
> Ashish Vijaywargiya
> HotWax Systems - est. 1997
> Connect with me on LinkedIn -
> https://www.linkedin.com/in/ashishvijaywargiya1
>
> On Thu, Jun 30, 2016 at 12:35 PM, Sharan Foga  wrote:
>
> > Thanks for the response -Jacopo. (You posted a minute before I did!)
> >
> > Anyway I think that I might have an idea that could solve our problem –
> > let's just leave 14.12 and 15.12 as unreleased branches.
> >
> > The jar issue is only an issue if we want to convert the unreleased
> > branches into a release. Unreleased they can contain the jar files and
> the
> > special purpose components etc – but if we want to release them then we
> > need to fix the jar file problem before it can be released.
> >
> > Christian mentions that people are using the unreleased branches, so by
> > leaving them unreleased, we are actually giving our users something that
> > can help them move from 13.07.
> >
> > So I suggest that we seriously consider leaving 14.12 and 15.12 as
> > unreleased branches.
> >
> > For the next point – I think our next release should be the 16.x – so
> that
> > means that we are not backporting any changes and can take a branch
> > directly from the trunk once the gradle changes have been applied.
> >
> > Comments anyone?
> >
> > Thanks
> > Sharan
> >
> >
> > On 2016-06-30 07:25 (+0200), Jacopo Cappellato <
> > jacopo.cappell...@hotwaxsystems.com> wrote:
> > > On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > > christian.geis...@isu-gmbh.de> wrote:
> > >
> > > > ...
> > > > My proposal is to release 14.12 ASAP, after that dropping 13.07 and
> > then
> > > > trying to do a release 16.x with Gradle. And a release of 15.12in
> > > > between wouldn't be bad either ;)
> > > >
> > > >
> > > Thank you Christian.
> > > Your proposal makes sense but the problem is that we will not be able
> to
> > > release (14.12, 15.12 etc...) until we have removed all the jars from
> the
> > > distribution, and implementing this in the branches will require some
> > > layout changes that will bring instability: the releases will be
> delayed
> > > regardless and if we want to implement two different mechanisms for
> > > downloading the jars for 14.12 vs the trunk and 16.x etc... than the
> > > codebases will become rather different and more difficult to maintain;
> > and
> > > the extra effort will have to be backed up by the interested users. We
> > have
> > > to consider these aspects and do a reality check on resources before
> > moving
> > > in any direction.
> > >
> > > Jacopo
> > >
> >
>

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

[Michael Brohl]

Great idea, +1

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 30.06.16 um 09:05 schrieb Sharan Foga:

Thanks for the response -Jacopo. (You posted a minute before I did!)

Anyway I think that I might have an idea that could solve our problem – let's 
just leave 14.12 and 15.12 as unreleased branches.

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

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

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

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

Comments anyone?

Thanks
Sharan


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

On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
christian.geis...@isu-gmbh.de> wrote:


...
My proposal is to release 14.12 ASAP, after that dropping 13.07 and then
trying to do a release 16.x with Gradle. And a release of 15.12in
between wouldn't be bad either ;)



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

Jacopo






smime.p7s
Description: S/MIME Cryptographic Signature

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

[Ashish Vijaywargiya]

+1, Very good idea. Thanks so much Sharan!

Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997
Connect with me on LinkedIn -
https://www.linkedin.com/in/ashishvijaywargiya1

On Thu, Jun 30, 2016 at 12:35 PM, Sharan Foga  wrote:

> Thanks for the response -Jacopo. (You posted a minute before I did!)
>
> Anyway I think that I might have an idea that could solve our problem –
> let's just leave 14.12 and 15.12 as unreleased branches.
>
> The jar issue is only an issue if we want to convert the unreleased
> branches into a release. Unreleased they can contain the jar files and the
> special purpose components etc – but if we want to release them then we
> need to fix the jar file problem before it can be released.
>
> Christian mentions that people are using the unreleased branches, so by
> leaving them unreleased, we are actually giving our users something that
> can help them move from 13.07.
>
> So I suggest that we seriously consider leaving 14.12 and 15.12 as
> unreleased branches.
>
> For the next point – I think our next release should be the 16.x – so that
> means that we are not backporting any changes and can take a branch
> directly from the trunk once the gradle changes have been applied.
>
> Comments anyone?
>
> Thanks
> Sharan
>
>
> On 2016-06-30 07:25 (+0200), Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
> > On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > christian.geis...@isu-gmbh.de> wrote:
> >
> > > ...
> > > My proposal is to release 14.12 ASAP, after that dropping 13.07 and
> then
> > > trying to do a release 16.x with Gradle. And a release of 15.12in
> > > between wouldn't be bad either ;)
> > >
> > >
> > Thank you Christian.
> > Your proposal makes sense but the problem is that we will not be able to
> > release (14.12, 15.12 etc...) until we have removed all the jars from the
> > distribution, and implementing this in the branches will require some
> > layout changes that will bring instability: the releases will be delayed
> > regardless and if we want to implement two different mechanisms for
> > downloading the jars for 14.12 vs the trunk and 16.x etc... than the
> > codebases will become rather different and more difficult to maintain;
> and
> > the extra effort will have to be backed up by the interested users. We
> have
> > to consider these aspects and do a reality check on resources before
> moving
> > in any direction.
> >
> > Jacopo
> >
>

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

[Ashish Vijaywargiya]

+1

Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997
Connect with me on LinkedIn -
https://www.linkedin.com/in/ashishvijaywargiya1

On Thu, Jun 30, 2016 at 1:35 PM, Taher Alkhateeb  wrote:

> Hi Sharan,
>
> Very smart idea simple and to the point. We avoid a mountain of work by
> simply not releasing. I see two major benefits of not making a new releases
> of 14 or 15
>
> 1- the compliance with no binaries issue for the ASF is automatically
> achieved without any work
> 2-  the community as a whole can now focus on the future by upgrading and
> migrating to the new releases where all the hot stuff is happening
>
> Under the special circumstances we are going through with this wake up call
> to refactor and improve the framework and the big new features being added
> it makes sense to unify our efforts.
>
> With that being said we need to focus our efforts on making a new release
> soon to have something tangible with all the goodies in the hands of our
> users.
>
> Taher Alkhateeb
> On Jun 30, 2016 10:05 AM, "Sharan Foga"  wrote:
>
> > Thanks for the response -Jacopo. (You posted a minute before I did!)
> >
> > Anyway I think that I might have an idea that could solve our problem –
> > let's just leave 14.12 and 15.12 as unreleased branches.
> >
> > The jar issue is only an issue if we want to convert the unreleased
> > branches into a release. Unreleased they can contain the jar files and
> the
> > special purpose components etc – but if we want to release them then we
> > need to fix the jar file problem before it can be released.
> >
> > Christian mentions that people are using the unreleased branches, so by
> > leaving them unreleased, we are actually giving our users something that
> > can help them move from 13.07.
> >
> > So I suggest that we seriously consider leaving 14.12 and 15.12 as
> > unreleased branches.
> >
> > For the next point – I think our next release should be the 16.x – so
> that
> > means that we are not backporting any changes and can take a branch
> > directly from the trunk once the gradle changes have been applied.
> >
> > Comments anyone?
> >
> > Thanks
> > Sharan
> >
> >
> > On 2016-06-30 07:25 (+0200), Jacopo Cappellato <
> > jacopo.cappell...@hotwaxsystems.com> wrote:
> > > On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > > christian.geis...@isu-gmbh.de> wrote:
> > >
> > > > ...
> > > > My proposal is to release 14.12 ASAP, after that dropping 13.07 and
> > then
> > > > trying to do a release 16.x with Gradle. And a release of 15.12in
> > > > between wouldn't be bad either ;)
> > > >
> > > >
> > > Thank you Christian.
> > > Your proposal makes sense but the problem is that we will not be able
> to
> > > release (14.12, 15.12 etc...) until we have removed all the jars from
> the
> > > distribution, and implementing this in the branches will require some
> > > layout changes that will bring instability: the releases will be
> delayed
> > > regardless and if we want to implement two different mechanisms for
> > > downloading the jars for 14.12 vs the trunk and 16.x etc... than the
> > > codebases will become rather different and more difficult to maintain;
> > and
> > > the extra effort will have to be backed up by the interested users. We
> > have
> > > to consider these aspects and do a reality check on resources before
> > moving
> > > in any direction.
> > >
> > > Jacopo
> > >
> >
>

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

[Taher Alkhateeb]

Hi Sharan,

Very smart idea simple and to the point. We avoid a mountain of work by
simply not releasing. I see two major benefits of not making a new releases
of 14 or 15

1- the compliance with no binaries issue for the ASF is automatically
achieved without any work
2-  the community as a whole can now focus on the future by upgrading and
migrating to the new releases where all the hot stuff is happening

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

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

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

> Thanks for the response -Jacopo. (You posted a minute before I did!)
>
> Anyway I think that I might have an idea that could solve our problem –
> let's just leave 14.12 and 15.12 as unreleased branches.
>
> The jar issue is only an issue if we want to convert the unreleased
> branches into a release. Unreleased they can contain the jar files and the
> special purpose components etc – but if we want to release them then we
> need to fix the jar file problem before it can be released.
>
> Christian mentions that people are using the unreleased branches, so by
> leaving them unreleased, we are actually giving our users something that
> can help them move from 13.07.
>
> So I suggest that we seriously consider leaving 14.12 and 15.12 as
> unreleased branches.
>
> For the next point – I think our next release should be the 16.x – so that
> means that we are not backporting any changes and can take a branch
> directly from the trunk once the gradle changes have been applied.
>
> Comments anyone?
>
> Thanks
> Sharan
>
>
> On 2016-06-30 07:25 (+0200), Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
> > On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> > christian.geis...@isu-gmbh.de> wrote:
> >
> > > ...
> > > My proposal is to release 14.12 ASAP, after that dropping 13.07 and
> then
> > > trying to do a release 16.x with Gradle. And a release of 15.12in
> > > between wouldn't be bad either ;)
> > >
> > >
> > Thank you Christian.
> > Your proposal makes sense but the problem is that we will not be able to
> > release (14.12, 15.12 etc...) until we have removed all the jars from the
> > distribution, and implementing this in the branches will require some
> > layout changes that will bring instability: the releases will be delayed
> > regardless and if we want to implement two different mechanisms for
> > downloading the jars for 14.12 vs the trunk and 16.x etc... than the
> > codebases will become rather different and more difficult to maintain;
> and
> > the extra effort will have to be backed up by the interested users. We
> have
> > to consider these aspects and do a reality check on resources before
> moving
> > in any direction.
> >
> > Jacopo
> >
>

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

[Sharan Foga]

Thanks for the response -Jacopo. (You posted a minute before I did!)

Anyway I think that I might have an idea that could solve our problem – let's 
just leave 14.12 and 15.12 as unreleased branches.

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

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

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

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

Comments anyone?

Thanks
Sharan


On 2016-06-30 07:25 (+0200), Jacopo Cappellato 
 wrote: 
> On Wed, Jun 29, 2016 at 11:49 AM, Christian Geisert <
> christian.geis...@isu-gmbh.de> wrote:
> 
> > ...
> > My proposal is to release 14.12 ASAP, after that dropping 13.07 and then
> > trying to do a release 16.x with Gradle. And a release of 15.12in
> > between wouldn't be bad either ;)
> >
> >
> Thank you Christian.
> Your proposal makes sense but the problem is that we will not be able to
> release (14.12, 15.12 etc...) until we have removed all the jars from the
> distribution, and implementing this in the branches will require some
> layout changes that will bring instability: the releases will be delayed
> regardless and if we want to implement two different mechanisms for
> downloading the jars for 14.12 vs the trunk and 16.x etc... than the
> codebases will become rather different and more difficult to maintain; and
> the extra effort will have to be backed up by the interested users. We have
> to consider these aspects and do a reality check on resources before moving
> in any direction.
> 
> Jacopo
>