Hi Gil,
Debian releases are approximately two years apart...
https://en.wikipedia.org/wiki/Debian_version_history
Cheers
Paul
On Sat, 25 Jan 2020 at 03:36, Gil Portenseigne
wrote:
> I wonder if it is bad for the project to have 2 years between two
> releases, 16 => 18 => 20
>
> WDYT ?
>
>
That could be a good idea Gil,
As I just said to Nicolas and Taher, though I'm not sure why (but the tools
missing?), I see less backporting since we turned to Git.
Maybe having less branches to backport to would help indeed...
Le 24/01/2020 à 17:36, Gil Portenseigne a écrit :
I wonder if it
I wonder if it is bad for the project to have 2 years between two
releases, 16 => 18 => 20
WDYT ?
Gil
On Fri, Jan 24, 2020 at 05:31:14PM +0100, Jacques Le Roux wrote:
> Le 24/01/2020 à 15:09, Nicolas Malin a écrit :
> > On 24/01/2020 14:57, Jacques Le Roux wrote:
> >
> > > I must say I'm
Le 24/01/2020 à 15:09, Nicolas Malin a écrit :
On 24/01/2020 14:57, Jacques Le Roux wrote:
I must say I'm mostly against because of the surplus of effort
necessary to backport to both R17 and R18
About R20, as Pierre Smits mentioned in Slack should we not create a
R19 before ;)
If we follow
On 24/01/2020 14:57, Jacques Le Roux wrote:
> Ah OK, It was not clear to me (and to Jacopo I guess), anyway the 1st
> vote was confusing, thanks for voting again.
I already done ;)
>
> I must say I'm mostly against because of the surplus of effort
> necessary to backport to both R17 and R18
>
>
Ah OK, It was not clear to me (and to Jacopo I guess), anyway the 1st vote was
confusing, thanks for voting again.
I must say I'm mostly against because of the surplus of effort necessary to
backport to both R17 and R18
About R20, as Pierre Smits mentioned in Slack should we not create a R19
Finally I voted to didn't skip the R17 in contradiction with my previous
message for the simple reason to respect the old deprecation code
process and increase the release activity.
For OFBiz integrator this change nothing because mostly use directly the
release branch on git, so the choice must
Hi All,
Since we don't have a consensus about my proposition and I don't see much
backporting efforts for about 3 months, I'll start a vote about it
Thanks
Jacques
Le 23/01/2020 à 14:35, Pierre Smits a écrit :
+1 on skipping r17
+1 on releasing first of r18
According to
+1 on skipping r17
+1 on releasing first of r18
According to
https://issues.apache.org/jira/projects/OFBIZ?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page=unreleased
the r18.12.01 is more ready to be released than r17.12.01.
Best regards,
Pierre Smits
*Apache Trafodion
According to
https://issues.apache.org/jira/projects/OFBIZ/versions/12338772 there is
not too much to do to get the r17 branch issues solved.
We could start an initiative to check the issues and their relevance,
fix the remaining and and do the release.
What do you think?
Thanks,
Michael
I am also in favor to get the r17 Branch released soon and not skipping it.
Thanks,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 09.10.19 um 11:56 schrieb Deepak Dixit:
Yes Jacques,
We can make 16 as old, release R17 as current release (once we officially
released it), start working on
Yes Jacques,
We can make 16 as old, release R17 as current release (once we officially
released it), start working on R18 to make it ready for release.
Kind Regards,
Deepak Dixit
On Wed, Oct 9, 2019 at 1:01 PM Jacques Le Roux
wrote:
> Hi Deepak,
>
> I have no problems with that. For demo R16
Hi Deepak,
I have no problems with that. For demo R16 would stay our stable or we could have it as old but not deprecated for instance? Ie we would continue to
maintain R16 (as we currently do as much as possible) it but not demo it and demo R17 as stable, right?
Jacques
Le 09/10/2019 à
I think due to one feature/bug skipping R17 is not good idea, I'll try to
backport this work to R17.
We all are working since long to make R17 stable, and I think R17 is in
good shape.
Making R16 deprecate, I think we need to think about Release life cycle,
release should have at least 5-7 year
Thanks Nicolas and Gil,
Because a release is an important thing, and without other answers than yours,
I'll start a vote for that
Jacques
Le 04/10/2019 à 15:27, Gil Portenseigne a écrit :
Hello,
I think that the one year stabilisation period needed for a new branch
to be released is not
Hello,
I think that the one year stabilisation period needed for a new branch
to be released is not that far for R18 (less than two month), so I
suppose that skipping R17 to avoid maintaining two release branches is a
good call.
Gil
Le 13:29 - samedi 28 sept., Jacques Le Roux a écrit :
> Hi,
>
I'm agree with idea to skip the R17 and go directly to R18,
We currently have many improvement and correction, present on R18 and
not R17 that are stable and fully functionnal
Nicolas
On 9/28/19 1:29 PM, Jacques Le Roux wrote:
Hi,
As reported by Rashi Dhagat in OFBIZ-11215 "Email password
Hi,
As reported by Rashi Dhagat in OFBIZ-11215 "Email password is not working" in
R16, and actually nor in R17.
It has been fixed in trunk and R18 with OFBIZ-4361. As mentioned there, it's
hard to backport to R17 not even speaking about R16!
I wonder if a case like that would not make R16
18 matches
Mail list logo
