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
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
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
+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
wrote:
> +1 to the initial proposal of release
>
> 3 years
+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
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
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 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
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 wrote:
> >>>3 years support of r17 and 5
>>>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
wrote:
> +1 for the initial proposal
>
> with an additional idea: maybe better skip r20 and make a r21 right at
> the beginning
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.r...@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
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
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
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
+1
I totally agree with Michael
Il giorno lun 21 dic 2020 alle ore 14:57 Michael Brohl <
michael.br...@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
+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
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
+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 &
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 <
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
20 matches
Mail list logo
