-
Notifications
You must be signed in to change notification settings - Fork 5
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
Release channels #1632
Comments
Since the Julia General registry requires semver, we'll need to split out the version number of Ribasim.jl from the other 2024.x.y version numbers. And then bump the major version each time we make a breaking release. Also we should document and annotate with
Right now we have Ribasim Python registered in conda-forge under the name |
I will discuss this with Marnix, but I think this is already the case
|
I added another bullet, publish Ribasim QGIS plugin. If our QGIS plugin stays more or less as is, it meets all requirements to publish it. If we want to use Ribasim Python in our plugin or bundle the executable, users need to probably use QGIS from conda-forge, e.g. @Huite what's your call on this? Should we go ahead and publish? Since the version numbers are linked, we might need to release QGIS plugins under new version numbers with no code changes. Considering the plugin registration is a manually curated process this is not ideal. But perhaps once we slow down / stabilize development that is not a big issue? |
@Jingru923 the download portal is https://download.deltares.nl/en/ribasim. That currently doesn't contain any information about this project, only Ribasim 7. |
I thought he meant the log that comes from our release pipeline.
I agree that Ribasim 9 should be on the page but I am doubting that if it is part of pipeline's outcome |
Yeah it wouldn't be part of the pipeline but a one time action to link to the latest release just like we do in https://deltares.github.io/Ribasim/install.html |
Regarding the QGIS plugin: there's no specific need to publish it right now. The main thing about the QGIS plugin repo is discoverability and ease of installation. I think those benefits are currently offset by the downsides of either having to re-upload the same plugin with a new version or having outdated (with regards to version) but identical plugin (with regards to code) online -- at some point the code is going to change, and then it won't be clear whether it needs a reupload and things get muddled. Regarding discoverability: people need to download the whole shebang from the Github pages anyway. Regarding ease of installation: still good, just click the zip. I'd say it's better to publish it on the long term. E.g. when you can move to some semblance of stability with e.g. two releases per year? Also worth noting: for stuff like imod-python, the primary way of getting it is through conda-forge. So there's a de facto less centralized way of downloading "all the stuff" which makes it more urgent (to me at least) to have the QGIS plugin published. For Ribasim, you would click the download links on the Github / Deltares page. |
I have written a document for the Software Distribution Plan, I want our products to be in line with each other and not have all kinds of exceptions to the rule. I'm alright with postponing the QGIS plugin to a later date if that is more fitting, but I would like to have it there for sure. I will send @Huite the document. |
I fully concur! I should've been more specific: I reckon a better time to publish it would be in half a year or so -- so still within the year goals. |
I made a PR on deltaforge's repo Deltares/deltaforge#18 |
I removed the label v1.0 as the remaining todos are planned for later/next year. |
I played around a bit with |
To align with the other Hydrology suite products additions are needed in our automatic release pipeline:
Requested by @deltamarnix / PMT Hydrology (see Software Distribution Plan )
Related issue: #1583
The text was updated successfully, but these errors were encountered: