Re: OFBiz 21.01 releases

Le 21/12/2022 à 12:33, Jacques Le Roux a écrit : The workaround is easy, the rest I doubt. Like this comment at top of GenericEntity.java     /** Contains the fields for this entity. Note that this should always be a *  HashMap to allow for two things: non-synchronized reads (synchronized

Re: OFBiz 21.01 releases

Le 21/12/2022 à 12:33, Jacques Le Roux a écrit : The workaround is easy, the rest I doubt. Like this comment at top of GenericEntity.java To be clear the issue I fixed with the workaround is about immutability

Re: OFBiz 21.01 releases

this change goes in to the code perhaps we should consider it a stop-gap to unblock moving OFBiz to JDK 17 as it seems to go again the spirit of strong encapsulation described in the migration guide you linked to: Migrating From JDK 8 to Later JDK Releases (oracle.com) <https://docs.oracle.co

Re: OFBiz 21.01 releases

to: Migrating >From JDK 8 to Later JDK Releases (oracle.com) <https://docs.oracle.com/en/java/javase/17/migrate/migrating-jdk-8-later-jdk-releases.html#GUID-7BB28E4D-99B3-4078-BDC4-FC24180CE82B>. I do support the workaround though as otherwise our option is to remain on older JDKs for the time b

Re: OFBiz 21.01 releases

ere would be no further releases for 18.12. Has there been any releases for version 21.01, and if so should they be downloadable from the ofbiz website? Thanks, Dan

Re: OFBiz 21.01 releases

l Watford wrote: Hello, The ofbiz project recently announced there would be no further releases for 18.12. Has there been any releases for version 21.01, and if so should they be downloadable from the ofbiz website? Thanks, Dan

Re: OFBiz 21.01 releases

disappointed to didn't find the time to present our work on the new decorator and theme for this release, but sure for the next :) Nicolas On 16/12/2022 10:12, Daniel Watford wrote: Hello, The ofbiz project recently announced there would be no further releases for 18.12. Has there been a

Re: OFBiz 21.01 releases

tor and theme for this release, but sure for the next :) Nicolas On 16/12/2022 10:12, Daniel Watford wrote: Hello, The ofbiz project recently announced there would be no further releases for 18.12. Has there been any releases for version 21.01, and if so should they be downloadable from the

Re: OFBiz 21.01 releases

h, I'm agree for the 22.01, I'm just disappointed to didn't find the time to present our work on the new decorator and theme for this release, but sure for the next :) Nicolas On 16/12/2022 10:12, Daniel Watford wrote: Hello, The ofbiz project recently announced there would be no further releases fo

Re: OFBiz 21.01 releases

: Yeah, I'm agree for the 22.01, I'm just disappointed to didn't find the time to present our work on the new decorator and theme for this release, but sure for the next :) Nicolas On 16/12/2022 10:12, Daniel Watford wrote: Hello, The ofbiz project recently announced there would be no furt

Re: OFBiz 21.01 releases

12/2022 10:12, Daniel Watford wrote: Hello, The ofbiz project recently announced there would be no further releases for 18.12. Has there been any releases for version 21.01, and if so should they be downloadable from the ofbiz website? Thanks, Dan

Re: OFBiz 21.01 releases

be no further releases for 18.12. Has there been any releases for version 21.01, and if so should they be downloadable from the ofbiz website? Thanks, Dan

Re: OFBiz 21.01 releases

, but it should be "soon" (ie in few weeks), hopefully using JDK 17 and Gradle 7.6... Jacques Le 16/12/2022 à 10:12, Daniel Watford a écrit : Hello, The ofbiz project recently announced there would be no further releases for 18.12. Has there been any releases for version 21.01, and if

Re: OFBiz 21.01 releases

; Not yet, but it should be "soon" (ie in few weeks), hopefully using JDK 17 > and Gradle 7.6... > > Jacques > > Le 16/12/2022 à 10:12, Daniel Watford a écrit : > > Hello, > > > > The ofbiz project recently announced there would be no further releases > for > >

Re: OFBiz 21.01 releases

Hi Daniel, Not yet, but it should be "soon" (ie in few weeks), hopefully using JDK 17 and Gradle 7.6... Jacques Le 16/12/2022 à 10:12, Daniel Watford a écrit : Hello, The ofbiz project recently announced there would be no further releases for 18.12. Has there been any releases f

OFBiz 21.01 releases

Hello, The ofbiz project recently announced there would be no further releases for 18.12. Has there been any releases for version 21.01, and if so should they be downloadable from the ofbiz website? Thanks, Dan -- Daniel Watford https://watfordconsulting.com <https://protect-eu.mimecast.

Re: OFBiz releases EOL (End Of Life) announcement

Le 10/01/2022 à 14:55, Jacopo Cappellato a écrit : On Mon, Jan 10, 2022 at 11:26 AM Jacques Le Roux wrote: Hi Jacopo, Would you be available soon to start the release work? Yes, I can work on it later today. Great! Also what about freezing a 22.01 branch? For the freezing of 22.01,

Re: OFBiz releases EOL (End Of Life) announcement

On Mon, Jan 10, 2022 at 11:26 AM Jacques Le Roux wrote: > > Hi Jacopo, > > Would you be available soon to start the release work? Yes, I can work on it later today. > > Also what about freezing a 22.01 branch? For the freezing of 22.01, we can proceed anytime: is there a volunteer to create

Re: OFBiz releases EOL (End Of Life) announcement

Hi Jacopo, Would you be available soon to start the release work? Also what about freezing a 22.01 branch? I'd like to then discuss the demos restart with Infra... TIA Jacques Le 07/01/2022 à 17:26, Jacques Le Roux a écrit : Hi, Jacopo and I came to an agreement at OFBIZ-12479. You can

Re: OFBiz releases EOL (End Of Life) announcement

Hi, Jacopo and I came to an agreement at OFBIZ-12479. You can still modify the draft if you feel so. I propose to start the release work after the weekend. It's a security issue. Jacques Le 05/01/2022 à 20:57, Jacques Le Roux a écrit : Le 05/01/2022 à 09:18, Jacques Le Roux a écrit : Le

Re: OFBiz releases EOL (End Of Life) announcement

Le 05/01/2022 à 09:18, Jacques Le Roux a écrit : Le 05/01/2022 à 09:14, Jacques Le Roux a écrit : I have created https://issues.apache.org/jira/browse/OFBIZ-12479 for that I have updated the Jira with a draft proposal, please comment there TIA Jacques

Re: OFBiz releases EOL (End Of Life) announcement [was Re: [ofbiz-site] branch master updated: More information about security and EOL (End Of Life)]

Jacques Le Roux: Hi All, I'd like to discuss about OFBiz releases EOL (End Of Life) announcement. For instance R17.12 is EOL with 17.12.08. I suggest to make it clear on site (if that's not already enough, eg*), to send an email to user ML and maybe talk about it in social-media and the blog

Re: OFBiz releases EOL (End Of Life) announcement

Le 05/01/2022 à 09:14, Jacques Le Roux a écrit : I have created https://issues.apache.org/jira/browse/OFBIZ-12479 for that

Re: OFBiz releases EOL (End Of Life) announcement

of the 18.12 branch with 17.12.08. Next time we will, like Struts, announce 6 months ago before the definitive announcement. I have created Jacques Le 04/01/2022 à 16:04, Jacques Le Roux a écrit : Hi All, I'd like to discuss about OFBiz releases EOL (End Of Life) announcement. For instance

Re: OFBiz releases EOL (End Of Life) announcement [was Re: [ofbiz-site] branch master updated: More information about security and EOL (End Of Life)]

a discussion for past-22.x Thanks, Michael Brohl ecomify GmbH - www.ecomify.de Am 04.01.22 um 16:04 schrieb Jacques Le Roux: Hi All, I'd like to discuss about OFBiz releases EOL (End Of Life) announcement. For instance R17.12 is EOL with 17.12.08. I suggest to make it clear on site

OFBiz releases EOL (End Of Life) announcement [was Re: [ofbiz-site] branch master updated: More information about security and EOL (End Of Life)]

Hi All, I'd like to discuss about OFBiz releases EOL (End Of Life) announcement. For instance R17.12 is EOL with 17.12.08. I suggest to make it clear on site (if that's not already enough, eg*), to send an email to user ML and maybe talk about it in social-media and the blog. Maybe we could

Re: [jira] [Commented] (OFBIZ-11094) Buildbot RAT for releases branches

42cb119cf3324d7cf3c2867d2092c72932aa6526 in ofbiz-tools's branch refs/heads/master from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-tools.git;h=42cb119 ] Fixed: Buildbot RAT for releases branches (OFBIZ-11094) Adds themes/common for R17 Buildbot RAT for releases branches

Re: OFBiz releases are failing verification checks

Furthermore, With recent https://github.com/apache/ofbiz-framework/pull/43 we don't need to deliver a convenience package containing both the base and the extensions anymore. This will enable (potential) adopters to evaluate/testdrive a fully operational OFBiz implementation in a contained

Re: OFBiz releases are failing verification checks

on, the releases in the two repos), it seems to me that you can go ahead by creating the .asc and .sha512 files for each of the releases in the repos and upload those together with those repo releases into http://downloads.apache.org/ofbiz. Met vriendelijke groet, Pierre Smits *Proud* *contributor** of* Apache

Re: OFBiz releases are failing verification checks

On Wed, Mar 4, 2020 at 4:12 PM Pierre Smits wrote: > [...] Recently the releases became available via the official repositories on > Github: > >- https://github.com/apache/ofbiz-framework/releases >- https://github.com/apache/ofbiz-plugins/releases > &

Re: OFBiz releases are failing verification checks

Hi Pierre, see my comments inline: On Wed, Mar 4, 2020 at 4:12 PM Pierre Smits wrote: > Hi all, > > Recently the releases became available via the official repositories on > Github: > >- https://github.com/apache/ofbiz-framework/releases >- https://github.com

OFBiz releases are failing verification checks

Hi all, Recently the releases became available via the official repositories on Github: - https://github.com/apache/ofbiz-framework/releases - https://github.com/apache/ofbiz-plugins/releases I tried to verify these with the function available in the ofbiz-tools rep, like: ../dev/asf

Re: [DISCUSSION] R16 and R17: email password issue and releases

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 =>

Re: [DISCUSSION] R16 and R17: email password issue and releases

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 mostly against b

Re: [DISCUSSION] R16 and R17: email password issue and releases

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: > >

Re: [DISCUSSION] R16 and R17: email password issue and releases

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

Re: [DISCUSSION] R16 and R17: email password issue and releases

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 > >

Re: [DISCUSSION] R16 and R17: email password issue and releases

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

Re: [DISCUSSION] R16 and R17: email password issue and releases

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

Re: [DISCUSSION] R16 and R17: email password issue and releases

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

Re: [DISCUSSION] R16 and R17: email password issue and releases

+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

Re: [DISCUSSION] R16 and R17: email password issue and releases

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

Re: [DISCUSSION] R16 and R17: email password issue and releases

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

Re: OFBiz & upcoming releases

Thanks Jacques, I see in referenced mail thread that several viewpoints and/or suggestions were made. However, nothing was concluded. Best regards, Pierre Smits *Apache Trafodion , Vice President* *Apache Directory , PMC Member*

Re: OFBiz & upcoming releases

Le 14/01/2020 à 12:40, Pierre Smits a écrit : Hi all, How are we moving forward getting to release something? Some time has passed since latest one (r16.11.06). Is there still value to be had for our adopters with a release from the r17.12 branch? If not, as there is already a superseding

OFBiz & upcoming releases

Hi all, How are we moving forward getting to release something? Some time has passed since latest one (r16.11.06). Is there still value to be had for our adopters with a release from the r17.12 branch? If not, as there is already a superseding branch (18.12), should we not stop spending effort

Re: [DISCUSSION] R16 and R17: email password issue and releases

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

Re: [DISCUSSION] R16 and R17: email password issue and releases

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 à

Re: [DISCUSSION] R16 and R17: email password issue and releases

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

Re: [DISCUSSION] R16 and R17: email password issue and releases

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

Re: [DISCUSSION] R16 and R17: email password issue and releases

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, >

Re: [DISCUSSION] R16 and R17: email password issue and releases

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

[DISCUSSION] R16 and R17: email password issue and releases

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

Re: AsciiDoc generated online documentation and releases

Le 22/11/2018 à 16:43, jler...@apache.org a écrit : Also, so far in Buildbot log only (not locally) I saw a message saying    asciidoctor: WARNING: could not embed image: /home/buildslave/slave/ofbizTrunkFrameworkPlugins/build/plugins/birt/src/docs/asciidoc/images/Report-Master.png; PNG uses

Re: AsciiDoc generated online documentation and releases

M Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: At https://cwiki.apache.org/confluence/display/OFBIZ/Draft+Documentation+Roadmap Sharan already suggested to "Backport to releases where possible" I think we should do that and not way R18 to use the AsciiDoc generation

Re: AsciiDoc generated online documentation and releases

; > Apache Incubator <https://incubator.apache.org>, committer > > > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without > > privileges) > > > since 2008* > > > Apache Steve <https://steve.apache.org>, committer > > > >

Re: AsciiDoc generated online documentation and releases

/steve.apache.org>, committer > > > > > > On Thu, Nov 15, 2018 at 12:59 PM Jacques Le Roux < > > jacques.le.r...@les7arts.com> wrote: > > > > > At > > > > > > https://cwiki.apache.org/confluence/display/OFBIZ/Draft+Documenta

Re: AsciiDoc generated online documentation and releases

thout privileges) > since 2008* > Apache Steve <https://steve.apache.org>, committer > > > On Thu, Nov 15, 2018 at 12:59 PM Jacques Le Roux < > jacques.le.r...@les7arts.com> wrote: > > > At > > > https://cwiki.apache.org/confluence/display/OFBIZ/Draft+Docu

Re: AsciiDoc generated online documentation and releases

eges) since 2008* Apache Steve <https://steve.apache.org>, committer On Thu, Nov 15, 2018 at 12:59 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > At > https://cwiki.apache.org/confluence/display/OFBIZ/Draft+Documentation+Roadmap > > Sharan already suggeste

Re: AsciiDoc generated online documentation and releases

At https://cwiki.apache.org/confluence/display/OFBIZ/Draft+Documentation+Roadmap Sharan already suggested to "Backport to releases where possible" I think we should do that and not way R18 to use the AsciiDoc generation even if it's not complete Opinions before I get ahead? Jacqu

AsciiDoc generated online documentation and releases

Hi, So start this discussion, currently our main documents in docs\asciidoc refer to the R17 release. But those document don't exist in R17 branch. I think it's not too late to backport them, but do we want to do so? Also I suggested to have an easy access to the documentation from the site

Re: Blocker issues and releases

You are maybe right, but we should not confuse the mean with the goal. It could be indeed that at a moment the checklist is unrealistic. Then,  before releasing, we should ask for each issue the person who sets the priority if s/he did for the reason documented in the wiki. If this person

Re: Blocker issues and releases

Many blocker issues are not really blocker (some of them in my opinion are trivial and not even worth a JIRA). I don't think this checklist is realistic. On Wed, Jul 4, 2018 at 2:45 PM, Rishi Solanki wrote: > Thanks Jacques!! > > > > Rishi Solanki > Sr Manager, Enterprise Software Development >

Re: Blocker issues and releases

Thanks Jacques!! Rishi Solanki Sr Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxsystems.com www.hotwax.co On Wed, Jul 4, 2018 at 12:56 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Hi committers, > > I have added a

Blocker issues and releases

Hi committers, I have added a line at https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz "Things to check before a release": "Check that no open blocker Jira issues are still pending" with a Jira filter The idea is that when you spot an issue which should

Re: svn commit: r1806762 [1/2] - in /ofbiz/site: ./ template/page/ template/page/releases/

rev=1806762=rev > Log: > Added two new pages for release notes, as release notes may be large so > its good idea to have independent page for each release notes. > > Added: > ofbiz/site/template/page/release-notes-13.07.03.tpl.php > - copied, changed from r1806761, of

Re: LoadDefault vs LoadDemo was [Re: Should we do binary releases?]

the old thread when > answering. I again forgot to create a new thread with a new brand message > and not a copy from the old thread. Also when answering you can remove "was > [Re: Should we do binary releases?]" in the subject, thanks!] > > > Hi Pierre, > > You did not get a

LoadDefault vs LoadDemo was [Re: Should we do binary releases?]

[PS to ALL: please forget the previous same message in the old thread when answering. I again forgot to create a new thread with a new brand message and not a copy from the old thread. Also when answering you can remove "was [Re: Should we do binary releases?]" in the subject, tha

LoadDefault vs LoadDemo was [Re: Should we do binary releases?]

Hi Pierre, You did not get a clear answer about LoadDefault here. Actually I think you got at least one from Taher elsewhere but I miss it. Anyway, I answer only to this part ("LoadDefault vs LoadDemo") inline below. Le 26/08/2016 à 18:27, Pierre Smits a écrit : [snip] Why should we consider

Re: Should we do binary releases?

Done Jacques Le 30/08/2016 à 08:09, Taher Alkhateeb a écrit : This is Shifting the subject from "should we do binary releases" to "How to deploy OFBiz without Gradle". Although this has been discussed extensively if you still want to discuss it I suggest to start

Re: Should we do binary releases?

This is Shifting the subject from "should we do binary releases" to "How to deploy OFBiz without Gradle". Although this has been discussed extensively if you still want to discuss it I suggest to start a new thread instead of changing the subject. On Aug 30, 2016 8:56

Re: Should we do binary releases?

Hi Nicolas, Taher, All, I also agree about not creating binary releases. At least not yet, this can be revisited... I just tried something which seemed very simple after reading Taher's suggestion in OFBIZ-7783 "For example if your problem is simply that you cannot build on a disconn

Re: Should we do binary releases?

aniverisary as a TLP. We should continue what we have done before with our releases.. './gradlew loadDefault ofbiz' is not providing a 1-statement experience ( are we not forgetting the additional 'cleanAll', but who is counting) './ofbiz start' is. <-- nice brand recognition/strengthening, by the

Re: Should we do binary releases?

Alkhateeb On Thu, Aug 25, 2016 at 9:04 PM, Pierre Smits <pierre.sm...@gmail.com> wrote: > Before I answer the question that Jacques raised ( rephrased into: Should > we generate binary packages aka zip files of our source releases as a > convenience to our potential and existing adopte

Re: Should we do binary releases?

Before I answer the question that Jacques raised ( rephrased into: Should we generate binary packages aka zip files of our source releases as a convenience to our potential and existing adopters?), I will give my take on why I believe projects do provide those to the broader audience. Projects

Re: Should we do binary releases?

Le 25/08/2016 à 13:16, Taher Alkhateeb a écrit : Glad you got the workarounds docs :) What do you mean by "your servers cannot connect to the Internet (but Internet can connect to them)"? Is that a DMZ, .iptables, port blocking, or what exactly? Sounds like what you're saying is not (no

Re: Should we do binary releases?

t : Hi Jacques, Sorry but I'm a little confused. I note the following: - OFBiz did not create binary releases in the past Mmm, this is a delicate thing, I'll not say more, you might check by yourself. - You started a thread to discuss whether we should create binary releases Yep, nothing preven

Re: Should we do binary releases?

nance,_risk_management,_and_compliance > > > Jacques > > >> Regards, >> >> Taher Alkhateeb >> >> On Thu, Aug 25, 2016 at 1:02 PM, Jacques Le Roux < >> jacques.le.r...@les7arts.com> wrote: >> >> Le 25/08/2016 à 11:33, Taher Alkhat

Re: Should we do binary releases?

Le 25/08/2016 à 11:33, Taher Alkhateeb a écrit : Hi Jacques, Sorry but I'm a little confused. I note the following: - OFBiz did not create binary releases in the past Mmm, this is a delicate thing, I'll not say more, you might check by yourself. - You started a thread to discuss whether

Re: Should we do binary releases?

t : > >> Hi Jacques, >> >> Sorry but I'm a little confused. I note the following: >> >> - OFBiz did not create binary releases in the past >> > > Mmm, this is a delicate thing, I'll not say more, you might check by > yourself. > > - You starte

Re: Should we do binary releases?

Le 25/08/2016 à 11:33, Taher Alkhateeb a écrit : Hi Jacques, Sorry but I'm a little confused. I note the following: - OFBiz did not create binary releases in the past Mmm, this is a delicate thing, I'll not say more, you might check by yourself. - You started a thread to discuss whether we

Re: Should we do binary releases?

Hi Jacques, Sorry but I'm a little confused. I note the following: - OFBiz did not create binary releases in the past - You started a thread to discuss whether we should create binary releases - When I ask you for the purpose of these releases you reply by saying, that's why I started

Re: Should we do binary releases?

ckages: focusing on publishing good (source) releases is already a challenging effort for this community; in the future, if a large set of users will start to ask for them, we could revisit this discussion Just my 2 cents Jacopo On Wed, Aug 24, 2016 at 4:36 PM, Jacques Le Roux < jacques.l

Re: Should we do binary releases?

sense as it is saying that you can provide binary releases that represent the binary form of YOUR code. Eventually it boils down to this http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201606.mbox/%3cCAAS6=7gvxghqekvefv_r1849qpi0+ca0jc2qwqbqfrdzncw...@mail.gmail.com%3e <> BT

Re: Should we do binary releases?

releases that represent the binary form of YOUR code. On a different but relevant note, why do we want binary releases in the first place? What is the purpose? This is not a desktop application or a web server that you just want to fire up and start using. There is preparation work (loading data

Re: Should we do binary releases?

Taher, Wait, either Tomcat, Ant and JMeter are doing it wrong or we don't understand this sentence (I agree with you) or it's incomplete. Because if you download each of their binary releases you will find in them "binary/bytecode files" which are not the "result of compilin

Re: Should we do binary releases?

Hi Jacques, The discussion we had in OFBIZ-7783 was basically around whether or not we should have a task to copy the gradle dependencies into a certain directory. We went through many discussions, the last one being that this task might be needed for binary releases. However, if you look

Should we do binary releases?

Hi, At https://issues.apache.org/jira/browse/OFBIZ-7783 we recently had a discussion with Taher about doing or not binary releases. This is how the ASF defines a binary release (http://www.apache.org/dev/release.html#what) <are also produced as a convenience to users that might not h

[jira] [Updated] (OFBIZ-6680) Backport all changes to currently supported releases

ges to currently supported releases > > > Key: OFBIZ-6680 > URL: https://issues.apache.org/jira/browse/OFBIZ-6680 > Project: OFBiz > Issue Type: Sub-task > Components: conten

[jira] [Updated] (OFBIZ-6680) Backport all changes to currently supported releases

ges to currently supported releases > > > Key: OFBIZ-6680 > URL: https://issues.apache.org/jira/browse/OFBIZ-6680 > Project: OFBiz > Issue Type: Bug > Component

[jira] [Updated] (OFBIZ-6680) Backport all changes to currently supported releases

1706159 1706162 1707857 1708274 1708930 1711519 (was: The revisions to backport are 1705329 1705417 1705427 1705532 1706159 1706162 1707857 1708930 1708274 1708560) > Backport all changes to currently supported releases > > >

[jira] [Updated] (OFBIZ-6680) Backport all changes to currently supported releases

1707857 1708930 1708274 1708560 > Backport all changes to currently supported releases > > > Key: OFBIZ-6680 > URL: https://issues.apache.org/jira/browse/OFBIZ-6680 > Project: OFBiz >

[jira] [Closed] (OFBIZ-6680) Backport all changes to currently supported releases

) (was: 14.12.01) There are much, too much conflicts I finally decided to not backport in supported releases branches > Backport all changes to currently supported releases > > > Key: OFBIZ-6680 >

[jira] [Assigned] (OFBIZ-6680) Backport all changes to currently supported releases

[ https://issues.apache.org/jira/browse/OFBIZ-6680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-6680: -- Assignee: Jacques Le Roux > Backport all changes to currently supported relea

[jira] [Created] (OFBIZ-6680) Backport all changes to currently supported releases

Jacques Le Roux created OFBIZ-6680: -- Summary: Backport all changes to currently supported releases Key: OFBIZ-6680 URL: https://issues.apache.org/jira/browse/OFBIZ-6680 Project: OFBiz Issue

Re: Upcoming releases according to our tentative schedule

this needs to be clarified with all the community Jacques Le 21/03/2015 08:54, Jacopo Cappellato a écrit : We never discussed this: we have mentioned the idea of re-adding them to the branch, not to releases, but didn't come to a conclusion; however this is not relevant for this thread about

Re: Upcoming releases according to our tentative schedule

with all the community Jacques Le 21/03/2015 08:54, Jacopo Cappellato a écrit : We never discussed this: we have mentioned the idea of re-adding them to the branch, not to releases, but didn't come to a conclusion; however this is not relevant for this thread about upcoming releases. Jacopo

Re: Upcoming releases according to our tentative schedule

specialpurpose components in R13.07 I think this needs to be clarified with all the community Jacques Le 21/03/2015 08:54, Jacopo Cappellato a écrit : We never discussed this: we have mentioned the idea of re-adding them to the branch, not to releases, but didn't come to a conclusion; however

Re: Upcoming releases according to our tentative schedule

never discussed this: we have mentioned the idea of re-adding them to the branch, not to releases, but didn't come to a conclusion; however this is not relevant for this thread about upcoming releases. Jacopo On Mar 20, 2015, at 10:25 PM, Jacques Le Rouxjacques.le.r...@les7arts.com wrote

Upcoming releases according to our tentative schedule

, not to releases, but didn't come to a conclusion; however this is not relevant for this thread about upcoming releases. Jacopo On Mar 20, 2015, at 10:25 PM, Jacques Le Rouxjacques.le.r...@les7arts.com wrote: Just a last remark about R13.07: so it means we have definitively abandoned

  1   2   3   >