You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2020/12/20 13:06:43 UTC

Releasing 17.12.05, 18.12.01 and freezing R20

Hi All,

We have no longer any pending security issues, even post-auth ones (those with no CVE). As Marj J. Cox  - VP of ASF security - said once to me: <<"No 
CVE" is a great outcome>> ;)

I propose that

  * we release 17.12.05 as the last release of R17.
  * We release 18.12.01 as the first release of R18.
  * That we make R18 our current stable branch, and so R17 the old one.
  * And finally that we freeze a new R20 branch.

What do you people think?

If it's OK with everybody could you handle it, or part of it if we don't agree on all, Jacopo?

Thanks

Jaques


Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by "jleroux@apache.org" <jl...@apache.org>.
Thanks Jacopo,

Looking forward and ready to help

Cheers

Jacques

PS: sent 5h ago but b.barracudacentral.org has a dent against me (hard to change that)

Le 21/12/2020 à 10:21, Jacopo Cappellato a écrit :
> Hi Jacques,
>
> It sounds like a good plan to me and I can prepare the artifacts as soon as
> we are ready.
> We could first publish 17.12.05 and then start the process for 18.12.01; in
> the meantime we could tag the new R20 branch.
>
> Thanks,
>
> Jacopo
>
>
> On Sun, Dec 20, 2020 at 2:08 PM Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Hi All,
>>
>> We have no longer any pending security issues, even post-auth ones (those
>> with no CVE). As Marj J. Cox  - VP of ASF security - said once to me: <<"No
>> CVE" is a great outcome>> ;)
>>
>> I propose that
>>
>>    * we release 17.12.05 as the last release of R17.
>>    * We release 18.12.01 as the first release of R18.
>>    * That we make R18 our current stable branch, and so R17 the old one.
>>    * And finally that we freeze a new R20 branch.
>>
>> What do you people think?
>>
>> If it's OK with everybody could you handle it, or part of it if we don't
>> agree on all, Jacopo?
>>
>> Thanks
>>
>> Jaques
>>
>>

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Nicola Mazzoni <ni...@mpstyle.it>.
+1

I totally agree with Michael

Il giorno lun 21 dic 2020 alle ore 14:57 Michael Brohl <
michael.brohl@ecomify.de> ha scritto:

> +1 for the initial proposal
>
> with an additional idea: maybe better skip r20 and make a r21 right at
> the beginning of the year with the chance to release also in 21.
>
> This would allow us to catch up and have a more up-to-date release
> cycle. It seems a bit outdated to read that r18 is released in 2021...
>
> What do you think?
>
> Also +1 for 3 years support of r17 and 5 years support starting with r18.
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 21.12.20 um 10:54 schrieb Jacques Le Roux:
> > Hi Deepak,
> >
> > The reason I propose that is because it's more and more difficult to
> > backport to R17, when for R18 it's still OK. Also 3 years seems good
> > enough for me.
> >
> > Of course if people think 5 years would be better then the backporting
> > question should be discussed...
> >
> > We could revise that later, because there was much change between R17
> > an trunk and there are less and less now. So we could support R18 for
> > 5 years
> >
> > Jacques
> >
> > Le 21/12/2020 à 10:38, Deepak Dixit a écrit :
> >> +1
> >>
> >> I have a question regarding the following point, rest looks good to me.
> >>
> >> What is the minimum supported year for a release?
> >> Do we have any policy regarding this?
> >>
> >> We should support a release for at least 5 year.
> >>
> >> Thoughts?
> >>
> >> Thanks & Regards
> >> --
> >> Deepak Dixit
> >> ofbiz.apache.org
> >>
> >>
> >> On Mon, Dec 21, 2020 at 2:51 PM Jacopo Cappellato <
> >> jacopo.cappellato@gmail.com> wrote:
> >>
>


-- 
Nicola Mazzoni


*Mp Styl**e Srl*
via Meucci, 37
41019 Limidi di Soliera (MO)
T 059/684916
M 347/9905529

www.mpstyle.it

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Gil Portenseigne <gi...@nereide.fr>.
+1 for Michael !

Cheers

On Mon, Dec 21, 2020 at 02:57:25PM +0100, Michael Brohl wrote:
> +1 for the initial proposal
> 
> with an additional idea: maybe better skip r20 and make a r21 right at the
> beginning of the year with the chance to release also in 21.
> 
> This would allow us to catch up and have a more up-to-date release cycle. It
> seems a bit outdated to read that r18 is released in 2021...
> 
> What do you think?
> 
> Also +1 for 3 years support of r17 and 5 years support starting with r18.
> 
> Thanks,
> 
> Michael Brohl
> 
> ecomify GmbH - www.ecomify.de
> 
> 
> Am 21.12.20 um 10:54 schrieb Jacques Le Roux:
> > Hi Deepak,
> > 
> > The reason I propose that is because it's more and more difficult to
> > backport to R17, when for R18 it's still OK. Also 3 years seems good
> > enough for me.
> > 
> > Of course if people think 5 years would be better then the backporting
> > question should be discussed...
> > 
> > We could revise that later, because there was much change between R17 an
> > trunk and there are less and less now. So we could support R18 for 5
> > years
> > 
> > Jacques
> > 
> > Le 21/12/2020 à 10:38, Deepak Dixit a écrit :
> > > +1
> > > 
> > > I have a question regarding the following point, rest looks good to me.
> > > 
> > > What is the minimum supported year for a release?
> > > Do we have any policy regarding this?
> > > 
> > > We should support a release for at least 5 year.
> > > 
> > > Thoughts?
> > > 
> > > Thanks & Regards
> > > -- 
> > > Deepak Dixit
> > > ofbiz.apache.org
> > > 
> > > 
> > > On Mon, Dec 21, 2020 at 2:51 PM Jacopo Cappellato <
> > > jacopo.cappellato@gmail.com> wrote:
> > > 

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Pawan Verma <pa...@apache.org>.
Big +1 to Michael's point of skipping R20 and make R21 at the beginning.
Maybe we can decide the timeline for its release.

Also, +1 for 3 years support of r17 and 5 years support starting with r18.

-- 
Thanks & Regards
Pawan Verma
ofbiz.apache.org


On Mon, Dec 21, 2020 at 8:26 PM jleroux@apache.org <jl...@apache.org>
wrote:

> Le 21/12/2020 à 14:57, Michael Brohl a écrit :
> > It seems a bit outdated to read that r18 is released in 2021...
>
> Sincerely I think we need to release R18, even at the end of 2020. Waiting
> one year more is too long...
>
> Jacques
>
>

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by "jleroux@apache.org" <jl...@apache.org>.
Le 21/12/2020 à 14:57, Michael Brohl a écrit :
> It seems a bit outdated to read that r18 is released in 2021... 

Sincerely I think we need to release R18, even at the end of 2020. Waiting one year more is too long...

Jacques


Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Eugen Stan <eu...@netdava.com>.
Hi,


On 02.09.2021 18:03, Nicolas Malin wrote:
> I reactivate this thread :)
> 
> Except if some remarks expressing reticence appears, I propose to
> 
> * publish the version 18.12.01 this month
> * create the release branch 21.09 with official support of java 11
> * migrate the trunk to support for java 17
> 
Looking forward to seeing Java 17 on trunk :).
That will certainly spark some cleanup and changes since the module 
system is enforced for java modules starting with 17.

-- 
Eugen Stan
+40720 898 747 / netdava.com

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi,

At least 18.12.01 release seems doable this month: https://s.apache.org/3ztp7

Jacques

Le 02/09/2021 à 17:03, Nicolas Malin a écrit :
> I reactivate this thread :)
>
> Except if some remarks expressing reticence appears, I propose to
>
> * publish the version 18.12.01 this month
> * create the release branch 21.09 with official support of java 11
> * migrate the trunk to support for java 17
>
> Suggest ?
>
> On 24/12/2020 06:18, Pranay Pandey wrote:
>> +1 to the original proposal and to the additional idea for skipping r20 and
>> making an r21.
>>
>> As discussed defining the 5 Years support policy will surely help.
>>
>> Best regards,
>> Pranay Pandey
>>
>>
>> On Tue, Dec 22, 2020 at 5:39 PM Aditya Sharma <ad...@apache.org>
>> wrote:
>>
>>> +1 to the initial proposal of release
>>>
>>> 3 years of support for r17 and 5 years of support starting with r18
>>> sounds good to me.
>>> I think we can define a policy well stated on our release page
>>>
>>>>> with an additional idea: maybe better skip r20 and make a r21 right at
>>>>> the beginning of the year with the chance to release also in 21.
>>> +1. We can think upon defining a timeline for stabilizing new release
>>> branches with a tentative time period like maybe 3-12 months. There
>>> are numerous new features that our users can benefit from and defining
>>> certain timelines may reduce the wait time.
>>>
>>> --
>>> Thanks and Regards,
>>> Aditya Sharma
>>>
>>> On Tue, Dec 22, 2020 at 4:38 PM Jacques Le Roux
>>> <ja...@les7arts.com> wrote:
>>>> Le 22/12/2020 à 10:08, Jacques Le Roux a écrit :
>>>>> If we don't release R20 it means that we will at best release R21 at
>>> the end of 2021, again a lot of years between 2018 and 2021.
>>>> OK forget it, OK this does not make sense, anyway it will be end of
>>> 2021, OK for me for a brand new R21 :)
>>>> But we need to release R18 ASAP...
>>>>
>>>> Jacques
>>>>

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Nicolas Malin <ni...@nereide.fr>.
I reactivate this thread :)

Except if some remarks expressing reticence appears, I propose to

* publish the version 18.12.01 this month
* create the release branch 21.09 with official support of java 11
* migrate the trunk to support for java 17

Suggest ?

On 24/12/2020 06:18, Pranay Pandey wrote:
> +1 to the original proposal and to the additional idea for skipping r20 and
> making an r21.
>
> As discussed defining the 5 Years support policy will surely help.
>
> Best regards,
> Pranay Pandey
>
>
> On Tue, Dec 22, 2020 at 5:39 PM Aditya Sharma <ad...@apache.org>
> wrote:
>
>> +1 to the initial proposal of release
>>
>> 3 years of support for r17 and 5 years of support starting with r18
>> sounds good to me.
>> I think we can define a policy well stated on our release page
>>
>>>> with an additional idea: maybe better skip r20 and make a r21 right at
>>>> the beginning of the year with the chance to release also in 21.
>> +1. We can think upon defining a timeline for stabilizing new release
>> branches with a tentative time period like maybe 3-12 months. There
>> are numerous new features that our users can benefit from and defining
>> certain timelines may reduce the wait time.
>>
>> --
>> Thanks and Regards,
>> Aditya Sharma
>>
>> On Tue, Dec 22, 2020 at 4:38 PM Jacques Le Roux
>> <ja...@les7arts.com> wrote:
>>> Le 22/12/2020 à 10:08, Jacques Le Roux a écrit :
>>>> If we don't release R20 it means that we will at best release R21 at
>> the end of 2021, again a lot of years between 2018 and 2021.
>>> OK forget it, OK this does not make sense, anyway it will be end of
>> 2021, OK for me for a brand new R21 :)
>>> But we need to release R18 ASAP...
>>>
>>> Jacques
>>>

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Pranay Pandey <pr...@hotwaxsystems.com>.
+1 to the original proposal and to the additional idea for skipping r20 and
making an r21.

As discussed defining the 5 Years support policy will surely help.

Best regards,
Pranay Pandey


On Tue, Dec 22, 2020 at 5:39 PM Aditya Sharma <ad...@apache.org>
wrote:

> +1 to the initial proposal of release
>
> 3 years of support for r17 and 5 years of support starting with r18
> sounds good to me.
> I think we can define a policy well stated on our release page
>
> > > with an additional idea: maybe better skip r20 and make a r21 right at
> > > the beginning of the year with the chance to release also in 21.
> +1. We can think upon defining a timeline for stabilizing new release
> branches with a tentative time period like maybe 3-12 months. There
> are numerous new features that our users can benefit from and defining
> certain timelines may reduce the wait time.
>
> --
> Thanks and Regards,
> Aditya Sharma
>
> On Tue, Dec 22, 2020 at 4:38 PM Jacques Le Roux
> <ja...@les7arts.com> wrote:
> >
> > Le 22/12/2020 à 10:08, Jacques Le Roux a écrit :
> > > If we don't release R20 it means that we will at best release R21 at
> the end of 2021, again a lot of years between 2018 and 2021.
> >
> > OK forget it, OK this does not make sense, anyway it will be end of
> 2021, OK for me for a brand new R21 :)
> >
> > But we need to release R18 ASAP...
> >
> > Jacques
> >
>

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Aditya Sharma <ad...@apache.org>.
+1 to the initial proposal of release

3 years of support for r17 and 5 years of support starting with r18
sounds good to me.
I think we can define a policy well stated on our release page

> > with an additional idea: maybe better skip r20 and make a r21 right at
> > the beginning of the year with the chance to release also in 21.
+1. We can think upon defining a timeline for stabilizing new release
branches with a tentative time period like maybe 3-12 months. There
are numerous new features that our users can benefit from and defining
certain timelines may reduce the wait time.

--
Thanks and Regards,
Aditya Sharma

On Tue, Dec 22, 2020 at 4:38 PM Jacques Le Roux
<ja...@les7arts.com> wrote:
>
> Le 22/12/2020 à 10:08, Jacques Le Roux a écrit :
> > If we don't release R20 it means that we will at best release R21 at the end of 2021, again a lot of years between 2018 and 2021.
>
> OK forget it, OK this does not make sense, anyway it will be end of 2021, OK for me for a brand new R21 :)
>
> But we need to release R18 ASAP...
>
> Jacques
>

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 22/12/2020 à 10:08, Jacques Le Roux a écrit :
> If we don't release R20 it means that we will at best release R21 at the end of 2021, again a lot of years between 2018 and 2021. 

OK forget it, OK this does not make sense, anyway it will be end of 2021, OK for me for a brand new R21 :)

But we need to release R18 ASAP...

Jacques


Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Guys,

If we don't release R20 it means that we will at best release R21 at the end of 2021, again a lot of years between 2018 and 2021.

I think we should release as much as possible, like the tendency is now and we did before.

Jacques

Le 22/12/2020 à 08:52, Devanshu Vyas a écrit :
> A big +1 to Michael's point for skipping R20 and make the R21 at the
> beginning of the new year.
> And for the 3years support of R17 and 5 years support starting with R18.
>
>
> Thanks & Regards,
> Devanshu Vyas.
>
>
> On Tue, Dec 22, 2020 at 10:55 AM Deepak Dixit <de...@apache.org> wrote:
>
>>>>> 3 years support of r17 and 5 years support starting with r18.
>> +1
>>
>>
>> Thanks & Regards
>> --
>> Deepak Dixit
>> ofbiz.apache.org
>>
>>
>> On Mon, Dec 21, 2020 at 7:27 PM Michael Brohl <mi...@ecomify.de>
>> wrote:
>>
>>> +1 for the initial proposal
>>>
>>> with an additional idea: maybe better skip r20 and make a r21 right at
>>> the beginning of the year with the chance to release also in 21.
>>>
>>> This would allow us to catch up and have a more up-to-date release
>>> cycle. It seems a bit outdated to read that r18 is released in 2021...
>>>
>>> What do you think?
>>>
>>> Also +1 for 3 years support of r17 and 5 years support starting with r18.
>>>
>>> Thanks,
>>>
>>> Michael Brohl
>>>
>>> ecomify GmbH - www.ecomify.de
>>>
>>>
>>> Am 21.12.20 um 10:54 schrieb Jacques Le Roux:
>>>> Hi Deepak,
>>>>
>>>> The reason I propose that is because it's more and more difficult to
>>>> backport to R17, when for R18 it's still OK. Also 3 years seems good
>>>> enough for me.
>>>>
>>>> Of course if people think 5 years would be better then the backporting
>>>> question should be discussed...
>>>>
>>>> We could revise that later, because there was much change between R17
>>>> an trunk and there are less and less now. So we could support R18 for
>>>> 5 years
>>>>
>>>> Jacques
>>>>
>>>> Le 21/12/2020 à 10:38, Deepak Dixit a écrit :
>>>>> +1
>>>>>
>>>>> I have a question regarding the following point, rest looks good to
>> me.
>>>>> What is the minimum supported year for a release?
>>>>> Do we have any policy regarding this?
>>>>>
>>>>> We should support a release for at least 5 year.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Thanks & Regards
>>>>> --
>>>>> Deepak Dixit
>>>>> ofbiz.apache.org
>>>>>
>>>>>
>>>>> On Mon, Dec 21, 2020 at 2:51 PM Jacopo Cappellato <
>>>>> jacopo.cappellato@gmail.com> wrote:
>>>>>

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Devanshu Vyas <vy...@gmail.com>.
A big +1 to Michael's point for skipping R20 and make the R21 at the
beginning of the new year.
And for the 3years support of R17 and 5 years support starting with R18.


Thanks & Regards,
Devanshu Vyas.


On Tue, Dec 22, 2020 at 10:55 AM Deepak Dixit <de...@apache.org> wrote:

> >>>3 years support of r17 and 5 years support starting with r18.
>
> +1
>
>
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
>
>
> On Mon, Dec 21, 2020 at 7:27 PM Michael Brohl <mi...@ecomify.de>
> wrote:
>
> > +1 for the initial proposal
> >
> > with an additional idea: maybe better skip r20 and make a r21 right at
> > the beginning of the year with the chance to release also in 21.
> >
> > This would allow us to catch up and have a more up-to-date release
> > cycle. It seems a bit outdated to read that r18 is released in 2021...
> >
> > What do you think?
> >
> > Also +1 for 3 years support of r17 and 5 years support starting with r18.
> >
> > Thanks,
> >
> > Michael Brohl
> >
> > ecomify GmbH - www.ecomify.de
> >
> >
> > Am 21.12.20 um 10:54 schrieb Jacques Le Roux:
> > > Hi Deepak,
> > >
> > > The reason I propose that is because it's more and more difficult to
> > > backport to R17, when for R18 it's still OK. Also 3 years seems good
> > > enough for me.
> > >
> > > Of course if people think 5 years would be better then the backporting
> > > question should be discussed...
> > >
> > > We could revise that later, because there was much change between R17
> > > an trunk and there are less and less now. So we could support R18 for
> > > 5 years
> > >
> > > Jacques
> > >
> > > Le 21/12/2020 à 10:38, Deepak Dixit a écrit :
> > >> +1
> > >>
> > >> I have a question regarding the following point, rest looks good to
> me.
> > >>
> > >> What is the minimum supported year for a release?
> > >> Do we have any policy regarding this?
> > >>
> > >> We should support a release for at least 5 year.
> > >>
> > >> Thoughts?
> > >>
> > >> Thanks & Regards
> > >> --
> > >> Deepak Dixit
> > >> ofbiz.apache.org
> > >>
> > >>
> > >> On Mon, Dec 21, 2020 at 2:51 PM Jacopo Cappellato <
> > >> jacopo.cappellato@gmail.com> wrote:
> > >>
> >
>

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Deepak Dixit <de...@apache.org>.
>>>3 years support of r17 and 5 years support starting with r18.

+1


Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org


On Mon, Dec 21, 2020 at 7:27 PM Michael Brohl <mi...@ecomify.de>
wrote:

> +1 for the initial proposal
>
> with an additional idea: maybe better skip r20 and make a r21 right at
> the beginning of the year with the chance to release also in 21.
>
> This would allow us to catch up and have a more up-to-date release
> cycle. It seems a bit outdated to read that r18 is released in 2021...
>
> What do you think?
>
> Also +1 for 3 years support of r17 and 5 years support starting with r18.
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 21.12.20 um 10:54 schrieb Jacques Le Roux:
> > Hi Deepak,
> >
> > The reason I propose that is because it's more and more difficult to
> > backport to R17, when for R18 it's still OK. Also 3 years seems good
> > enough for me.
> >
> > Of course if people think 5 years would be better then the backporting
> > question should be discussed...
> >
> > We could revise that later, because there was much change between R17
> > an trunk and there are less and less now. So we could support R18 for
> > 5 years
> >
> > Jacques
> >
> > Le 21/12/2020 à 10:38, Deepak Dixit a écrit :
> >> +1
> >>
> >> I have a question regarding the following point, rest looks good to me.
> >>
> >> What is the minimum supported year for a release?
> >> Do we have any policy regarding this?
> >>
> >> We should support a release for at least 5 year.
> >>
> >> Thoughts?
> >>
> >> Thanks & Regards
> >> --
> >> Deepak Dixit
> >> ofbiz.apache.org
> >>
> >>
> >> On Mon, Dec 21, 2020 at 2:51 PM Jacopo Cappellato <
> >> jacopo.cappellato@gmail.com> wrote:
> >>
>

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Michael Brohl <mi...@ecomify.de>.
+1 for the initial proposal

with an additional idea: maybe better skip r20 and make a r21 right at 
the beginning of the year with the chance to release also in 21.

This would allow us to catch up and have a more up-to-date release 
cycle. It seems a bit outdated to read that r18 is released in 2021...

What do you think?

Also +1 for 3 years support of r17 and 5 years support starting with r18.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 21.12.20 um 10:54 schrieb Jacques Le Roux:
> Hi Deepak,
>
> The reason I propose that is because it's more and more difficult to 
> backport to R17, when for R18 it's still OK. Also 3 years seems good 
> enough for me.
>
> Of course if people think 5 years would be better then the backporting 
> question should be discussed...
>
> We could revise that later, because there was much change between R17 
> an trunk and there are less and less now. So we could support R18 for 
> 5 years
>
> Jacques
>
> Le 21/12/2020 à 10:38, Deepak Dixit a écrit :
>> +1
>>
>> I have a question regarding the following point, rest looks good to me.
>>
>> What is the minimum supported year for a release?
>> Do we have any policy regarding this?
>>
>> We should support a release for at least 5 year.
>>
>> Thoughts?
>>
>> Thanks & Regards
>> -- 
>> Deepak Dixit
>> ofbiz.apache.org
>>
>>
>> On Mon, Dec 21, 2020 at 2:51 PM Jacopo Cappellato <
>> jacopo.cappellato@gmail.com> wrote:
>>

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Deepak Dixit <de...@apache.org>.
Thanks Jacques, sounds good to me.


Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org


On Mon, Dec 21, 2020 at 3:24 PM Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> Hi Deepak,
>
> The reason I propose that is because it's more and more difficult to
> backport to R17, when for R18 it's still OK. Also 3 years seems good enough
> for me.
>
> Of course if people think 5 years would be better then the backporting
> question should be discussed...
>
> We could revise that later, because there was much change between R17 an
> trunk and there are less and less now. So we could support R18 for 5 years
>
> Jacques
>
> Le 21/12/2020 à 10:38, Deepak Dixit a écrit :
> > +1
> >
> > I have a question regarding the following point, rest looks good to me.
> >
> > What is the minimum supported year for a release?
> > Do we have any policy regarding this?
> >
> > We should support a release for at least 5 year.
> >
> > Thoughts?
> >
> > Thanks & Regards
> > --
> > Deepak Dixit
> > ofbiz.apache.org
> >
> >
> > On Mon, Dec 21, 2020 at 2:51 PM Jacopo Cappellato <
> > jacopo.cappellato@gmail.com> wrote:
> >
>

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Deepak,

The reason I propose that is because it's more and more difficult to backport to R17, when for R18 it's still OK. Also 3 years seems good enough for me.

Of course if people think 5 years would be better then the backporting question should be discussed...

We could revise that later, because there was much change between R17 an trunk and there are less and less now. So we could support R18 for 5 years

Jacques

Le 21/12/2020 à 10:38, Deepak Dixit a écrit :
> +1
>
> I have a question regarding the following point, rest looks good to me.
>
> What is the minimum supported year for a release?
> Do we have any policy regarding this?
>
> We should support a release for at least 5 year.
>
> Thoughts?
>
> Thanks & Regards
> --
> Deepak Dixit
> ofbiz.apache.org
>
>
> On Mon, Dec 21, 2020 at 2:51 PM Jacopo Cappellato <
> jacopo.cappellato@gmail.com> wrote:
>

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Deepak Dixit <de...@apache.org>.
+1

I have a question regarding the following point, rest looks good to me.

>>>  * we release 17.12.05 as the last release of R17.

What is the minimum supported year for a release?
Do we have any policy regarding this?

We should support a release for at least 5 year.

Thoughts?

Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org


On Mon, Dec 21, 2020 at 2:51 PM Jacopo Cappellato <
jacopo.cappellato@gmail.com> wrote:

> Hi Jacques,
>
> It sounds like a good plan to me and I can prepare the artifacts as soon as
> we are ready.
> We could first publish 17.12.05 and then start the process for 18.12.01; in
> the meantime we could tag the new R20 branch.
>
> Thanks,
>
> Jacopo
>
>
> On Sun, Dec 20, 2020 at 2:08 PM Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
> > Hi All,
> >
> > We have no longer any pending security issues, even post-auth ones (those
> > with no CVE). As Marj J. Cox  - VP of ASF security - said once to me:
> <<"No
> > CVE" is a great outcome>> ;)
> >
> > I propose that
> >
> >   * we release 17.12.05 as the last release of R17.
> >   * We release 18.12.01 as the first release of R18.
> >   * That we make R18 our current stable branch, and so R17 the old one.
> >   * And finally that we freeze a new R20 branch.
> >
> > What do you people think?
> >
> > If it's OK with everybody could you handle it, or part of it if we don't
> > agree on all, Jacopo?
> >
> > Thanks
> >
> > Jaques
> >
> >
>

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Posted by Jacopo Cappellato <ja...@gmail.com>.
Hi Jacques,

It sounds like a good plan to me and I can prepare the artifacts as soon as
we are ready.
We could first publish 17.12.05 and then start the process for 18.12.01; in
the meantime we could tag the new R20 branch.

Thanks,

Jacopo


On Sun, Dec 20, 2020 at 2:08 PM Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:

> Hi All,
>
> We have no longer any pending security issues, even post-auth ones (those
> with no CVE). As Marj J. Cox  - VP of ASF security - said once to me: <<"No
> CVE" is a great outcome>> ;)
>
> I propose that
>
>   * we release 17.12.05 as the last release of R17.
>   * We release 18.12.01 as the first release of R18.
>   * That we make R18 our current stable branch, and so R17 the old one.
>   * And finally that we freeze a new R20 branch.
>
> What do you people think?
>
> If it's OK with everybody could you handle it, or part of it if we don't
> agree on all, Jacopo?
>
> Thanks
>
> Jaques
>
>