Roadmap for 2.1.0

[GregaVrbancic]

Dear contributors and users,

Today, we finally released a stable version 2.0.0. The packages are already uploaded and available for installation via PyPI and Anaconda. I am sure that Fedora native packages will be also available quite soon.

It took us quite some time to finally arrive to this stage, where we can say that the NiaPy API is mature enough, and it would serve us well in the future. Due to the large number of added features and improvements, in the times between the last stable release of NiaPy version 1.x and version 2.0.0 the API changed quite heavily and more frequently as we would like it. So at this point, we would like to thank all the users for the patience in those times of heavy development.

Of course, this could not be possible without our amazing contributors. Special mention goes to @firefly-cpp and @zStupan which are responsible for some major and crucial improvements in the codebase, which brought the NiaPy to the level at which we could release the stable version 2.0.0.

However, with this release, the work does not end, so I would like to invite all the contributors and users to give us some feedback and ideas for future 2.1.0 release of NiaPy.

[sisco0]

1. Maybe going further with the NiaPy-GUI project could help us on extending the reachability of this powerful library, as our tool could be used for getting a graphical first approach to optimization algorithms for first-time optimization algorithms students at universities. Related issue is Graphical user interface (GUI) for NiaPy  #330.
2. Also, on that behalf; are we planning to extend our library with Federated/Distributed Optimization algorithms? I ask this as we could add examples for getting our algorithms running on cloud platforms (such as AWS) by the use of tools such as Terraform. This is already approached for Machine learning solutions at the Flower project.
3. This proposal goes very in line with the previous one as I propose that we could go on with creating distributed (or isolated) optimization algorithms that could run on the web browser by the use of WebAssembly using a micropython-based build through emcc.

I know that the main purpose of NiaPy is not efficiency but clarity on optimization algorithms execution, but we could grab these numbered advices presented for setting up new projects on top in elsecase.

[GregaVrbancic]

Thanks for the feedback @sisco0. NiaPy-GUI is most definitely a path worth of pursuit. For this future task, I would suggest, we open a separate issue in the NiaPy-GUI repository, to discuss project setup and functionalities which we would like to have implemented.

[GregaVrbancic]

Functionalities and/or issues for which I think it would be nice to have it implemented in version 2.1.0 I would suggest:

• Refactor algorithms using Individual as proposed in [https://github.com/GWO returns different type of results (individual) than other methods #282#issuecomment-855232867](this comment) by @zStupan .
• Executing tests on GitHub Actions quicker (trying to address this in pull request Add pytest-testmon to reduce the execution time of tests. #366).
• Potentially migrate all tooling from pipenv to poetry, which would also result in a tidier repository (currently there are a lot of different config files in project root).
• Explore potential possibilities and performance gains if we would include Numba in NiaPy project.

[GregaVrbancic]

Since some major improvements and changes were made to NiaPy the version 2.1.0 was released yesterday, therefore I am closing this discussion and creating new one for version 2.2.0.