Created attachment 253530 [details] Update numpy to 2.1.1 and scipy to 1.14.1 numpy2 released for a long time, there are 2 choice for us to update numpy: 1) create a new port: math/py-numpy2 2) update math/py-numpy to 2.x and create math/py-numpy1 if necessary I tried both ways now I would like select 2, althought it would break many ports. We can fix it, actually many ports hold the update waiting for numpy2. When update numpy, scipy should be updated together, and pandas, and pythran. With this patches, numpy-2.1.1 and scipy-1.14.1 build well and run well, numpy-2.1.1 pass all tests, scipy-1.14.1 has only 6 fails in all tests. Any suggestions welcomed !
(In reply to wen from comment #0) I would not even break many ports, but also people's stuff having 1.x unter that port/package name.
At first I'm inclined to agree with option 1 due to the types of consumers (ahem, academic-type software) involved, but a quick look of numpy's development trajectory seems to suggest that only 2.x is to have serious development support going forward so option 2 seems more reasonable. Changing consumers that rely on 1.x to a new port directory/name, given that both the referenced software remains the same and can co-exist, does not constitute a POLA trigger.
(In reply to Charlie Li from comment #2) I am not an academic users. We are heavy industry and use numpy serious computations. If something like this changes I need to trigger several engineers to review/validate/release a lot of Python software. They give the development pace, not the IT (me) department.
Reminder: a NumPy 2.0 migration guide is available at https://numpy.org/doc/stable/numpy_2_0_migration_guide.html
(In reply to Michael Osipov from comment #3) I understand where you're coming from, but at some point, your processes cannot become ports' problem in terms of medium-/long-term maintenance, especially when reflecting upstreams' current (stable) development and support focuses. There are other examples in ports where an upstream project released a new major breaking version, the port updated to such due to upstream's focus going forward, but the previous (unchanged) version copied to a different directory name with those consumers reflecting the change.
1. Will make things backward compatible on existing setups / scripts and will clearly distinguish new version. Other ports that require version 2 can just update dependencies to py-numpy2 right? 2. Would work like gnupg where security/gnupg is the current version 2 while security/gnupg1 is the old version 1. But it is a bit confusing. 3. There is also third option to use py-numpy1 for version 1, py-numpy2 for version 2, and py-numpy (metaport) for the most recent version. This seems both versatile and provides best compatibility no matter what version shows in future. It will break current setups though. This approach is used for instance with drm-kmod packages (drm-510-kmod for version 5.10, drm-515-kmod for version 5.15, drm-61-kmod for version 6.1, and just drm-kmod metaport for the latest one whatever it is and matches the system requirements). I like this approach most. Only option 1 does not break existing setups. For option 2 or 3 change is only '1` added to the package name to maintain compatibilty.
(In reply to Charlie Li from comment #5) The process in this case is quite simple: Create a new port, let it sift in, mark the old one as deprecated for a good amount of time, wait for reactions, remove.
(In reply to Tomasz "CeDeROM" CEDRO from comment #6) I would only go for option three if the ports tree requires it and dependent ports need it. Otherwise it cases too much work.
py-numpy1 seems to be in use and might be still in use in future for various reasons so it may be good to provide that package as well?