-
Notifications
You must be signed in to change notification settings - Fork 887
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs(framework) Update how to upgrade to Flower 1.13 documentation #4533
Conversation
dstripelis
commented
Nov 18, 2024
- Added server and client app examples for versions 1.11+.
- Moved sentence highlighting to latest flower versions.
…g examples for Flower versions 1.11 and above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dstripelis Thanks for starting this update! There're 2 large parts that need to be updated:
- On the Deployment Engine, we no longer use
flower-server-app
andflower-client-app
. These need to be removed. Maybe you can work together with @Robert-Steiner since he has PR docs(framework) Add how-to run flwr with deployment engine guide #4372 which also updates the deployment engine mode. The secure connection part also needs to be updated (e.g. by referring todoc/source/docker/enable-tls.rst
in docs(framework:skip) Update Docker docs for 1.13.0 #4470). - On the Simulation Engine, let's update to the latest
server_fn
andclient_fn
usage. We should start either modes by usingflwr run
, and keeprun_simulation
for running in notebooks (less use and emphasized).
…he different flower simulation versions.
…pernode and adding respective api references.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also remove the requirements.txt
comment at the top of the document as well as the "Using Poetry" section? Although people can choose to use them, neither of those will work in a deployment setup that relies on the FAB-delivery mechanism. Because of this I think it's better to remove them.
Another point, I'm wondering if it would be better to split the code blocks for ClientApp
, ServerApp
, Simulation CLI
and Simulation Notebook
into several (one for current method, other for before 1.1x.0, other for the super legacy method). I think that way would be easier to spot the differences.
@jafermarq thank you for the insightful feedback. In the latest commit I addressed all comments except for splitting the code blocks for ClientApp, ServerApp, Simulation CLI and Simulation Notebook into several ones. We should do this in the next release since there are many pieces that need to be moved around in order to support this. In the future, we could even have entirely different doc pages for different versions, e.g., Overall the latest commit does the following:
|