Releasing 17.12.05, 18.12.01 and freezing R20

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Releasing 17.12.05, 18.12.01 and freezing R20

Jacques Le Roux
Administrator
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

Reply | Threaded
Open this post in threaded view
|

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Jacopo Cappellato-3
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 <
[hidden email]> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Deepak Dixit-5
+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 <
[hidden email]> 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 <
> [hidden email]> 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
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Jacques Le Roux
Administrator
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 <
> [hidden email]> wrote:
>
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Michael Brohl-3
+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 <
>> [hidden email]> wrote:
>>
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Nicola Mazzoni
+1

I totally agree with Michael

Il giorno lun 21 dic 2020 alle ore 14:57 Michael Brohl <
[hidden email]> 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 <
> >> [hidden email]> wrote:
> >>
>


--
Nicola Mazzoni


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

www.mpstyle.it
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 17.12.05, 18.12.01 and freezing R20

jleroux@apache.org
In reply to this post by Jacopo Cappellato-3
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 <
> [hidden email]> 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
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 17.12.05, 18.12.01 and freezing R20

jleroux@apache.org
In reply to this post by Michael Brohl-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Pawan Verma-2
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 [hidden email] <[hidden email]>
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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Deepak Dixit-5
In reply to this post by Jacques Le Roux
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 <
[hidden email]> 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 <
> > [hidden email]> wrote:
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Deepak Dixit-5
In reply to this post by Michael Brohl-3
>>>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 <[hidden email]>
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 <
> >> [hidden email]> wrote:
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Devanshu Vyas-2
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 <[hidden email]> 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 <[hidden email]>
> 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 <
> > >> [hidden email]> wrote:
> > >>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Gil Portenseigne
In reply to this post by Michael Brohl-3
+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 <
> > > [hidden email]> wrote:
> > >

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Jacques Le Roux
Administrator
In reply to this post by Devanshu Vyas-2
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 <[hidden email]> 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 <[hidden email]>
>> 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 <
>>>>> [hidden email]> wrote:
>>>>>
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Jacques Le Roux
Administrator
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

Reply | Threaded
Open this post in threaded view
|

Re: Releasing 17.12.05, 18.12.01 and freezing R20

adityasharma
+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
<[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 17.12.05, 18.12.01 and freezing R20

Pranay Pandey-3
+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 <[hidden email]>
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
> <[hidden email]> 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
> >
>