Hi Daniel,
As long as Docker Hub is not concerned it's OK with me:
https://blog.alexellis.io/docker-is-deleting-open-source-images/
https://devclass.com/2023/03/15/docker-to-users-of-free-team-orgs-one-month-to-pay-up-or-we-freeze-account-and-images-go/
This looks like things that happened in the past with other "free"
"organisations" (if it's free your are the product, don't do evil, etc.)
Jacques
Le 15/03/2023 à 12:31, Daniel Watford a écrit :
Hi Michael,
Users will not experience any changes except for the presence of some new
files in the ofbiz-framework repository.
These new files will not affect the regular build process.
The README is not being changed to mention docker in any way, so the
standard entry point for new users will still refer users to the regular
build process.
A new DOCKER.md file, present in the root of the ofbiz-framework repository
will describe building and deployment of OFBiz using Docker for interested
users. Further, a docker directory will be added, containing resources to
support the build of container images along with examples of how to deploy
them.
In summary, no change to the build and deployment approach currently
experienced by users.
Thanks,
Dan.
On Tue, 14 Mar 2023 at 20:52, michael.br...@ecomify.de <
michael.br...@ecomify.de> wrote:
Hi Dan,
I am on vacation so I am not able to work through the extensive
informations you provided.
What impact has the merge for the functionality, build system or other
parts of OFBiz?
Or, asked differently: what is changing for users who don‘t use docker to
run OFBiz?
Thanks for all your work,
Michael
Am 14.03.2023 um 14:47 schrieb Daniel Watford <d...@foomoo.co.uk>:
Hello,
In my recent email regarding Docker and OFBiz [1] I included some
proposed
next steps.
This email is to establish a lazy consensus [2] around the first
proposed
step, merging the experimental-docker branch into trunk and adapting
those
changes to build and push 'snapshot' images to ghcr.io/apache/ofbiz in
response to trunk commits.
The proposal listed the 3 image variants that would be produced from
trunk,
and how each variant would be assigned 2 tags, snapshot and {{sha}}.
I now propose dropping the {{sha}} image tag to reduce noise in the list
of
container images. The {{sha}} tags can be re-implemented later if a need
arises.
No work on this proposal will begin for at least 72 hours from the time
of
sending this email.
Other steps proposed in my previous email [1] are excluded from this lazy
consensus and shall be addressed in their own email threads.
Thanks,
Dan.
[1] https://lists.apache.org/thread/njg7fgwxjxt1vsfs6df8rrwvyp5pwv9p
[2] https://community.apache.org/committers/lazyConsensus.html
--
Daniel Watford
