You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@jkrasting has created a fork of @raphaeldussin's OM4labs, which he has renamed https://github.com/jkrasting/omlabs, reflecting the move towards OM5 (and presumably dropping the version from the name as an implication of some backwards and forwards portability).
My experience is that making downstream forks the de facto main branch of a package leads to frustrations down the line, e.g. because forks cannot host their own issues and can not (at least easily) be published to PyPi / conda-forge.
The changes on my fork are ready to be pushed to the newly created OMLabs repo located within the MOM Community organization once @raphaeldussin puts the finishing touches on the org settings.
I also configured some versioning and GitHub actions to automatically deploy new releases to PyPi. We can migrate this as well to the new repo.
@jkrasting has created a fork of @raphaeldussin's OM4labs, which he has renamed https://github.com/jkrasting/omlabs, reflecting the move towards OM5 (and presumably dropping the version from the name as an implication of some backwards and forwards portability).
My experience is that making downstream forks the de facto main branch of a package leads to frustrations down the line, e.g. because forks cannot host their own issues and can not (at least easily) be published to PyPi / conda-forge.
Is the plan for raphaeldussion/om4labs to be the eventual home for OMlabs, or https://github.com/jkrasting/omlabs, or for a new package
OMlabs
package to started from scratch?The text was updated successfully, but these errors were encountered: