Skip to content
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

Renaming / branding #88

Open
SylvainCorlay opened this issue Oct 14, 2020 · 5 comments
Open

Renaming / branding #88

SylvainCorlay opened this issue Oct 14, 2020 · 5 comments
Assignees
Labels
maintenance Maintenance task

Comments

@SylvainCorlay
Copy link
Member

Do you think it would be interesting to rename the project into "conda / mamba navigator" now that it has a standalone mode? (we also thought of of "gator" :).

Happy to discuss this in person! cc @jtpio @fcollonval

@fcollonval
Copy link
Member

Hey yes we can definitely discuss about it. I'm available next week if you want.

Regarding the new name, the main question I have is more about how to avoid update break for the user. One idea would be to have a multiple outputs conda recipe.

@fcollonval fcollonval added the maintenance Maintenance task label Oct 18, 2020
@jtpio
Copy link
Member

jtpio commented Nov 4, 2020

Posting for visibility. Here is the plan and ideas we discussed in person:

  • Base the Navigator on lumino Application and not JupyterLab to reduce its size and boundaries (to discuss)
  • On the frontend, use a JupyterApp rather than JupyterLab server: Create a simple server for the navigator #92
  • Rename the Python package to mamba-gator, do a release of the package with JLab2, classical NB and the Navigator support
  • It should inform classical NB user that this is the latest release. In the future, they will need to use the stand alone Navigator.
  • In classical NB the old entry points in tree and notebook open the stand alone navigator in a new tab
  • Then migrate to JLab3 (Update to JupyterLab 3.0 #89) and drop support for the classical Notebook

Items 1 and 2 can be tracked separately and shouldn't affect the renaming / branding.

Items 3 and 4 can be done now. Then we can tackle item 5 to add support for JupyterLab 3+ on master.

@fcollonval feel free to correct if some details are missing or need to be updated

@fcollonval
Copy link
Member

Thanks @jtpio

@fcollonval
Copy link
Member

Now that #95 and #97 are in. We could move ahead with a release of a single package and ensure backward compatibility for the conda package by creating two outputs packages: one named mamba-gator (to match the one on pip) and one jupyter_conda (to trigger update on existing installation).

I propose as final naming:
common => @mamba-org/gator-common (@mamba-org/common is to generic if other mamba projects start publishing on npm)
labextension => @mamba-org/gator-lab

Regarding versioning, I suggest 4.0.0 for python and a common version 2.0.0 for the npm packages (to reflect they are based on JLab 2). Will unmatching version between python and npm brings trouble when migrating to JLab 3?

@jtpio @SylvainCorlay what do you think?

@jtpio
Copy link
Member

jtpio commented Nov 16, 2020

Thanks @fcollonval.

@mamba-org/common is to generic if other mamba projects start publishing on npm

Yes it would make sense to go for a less generic name (@mamba-org/gator-common sounds good).

Will unmatching version between python and npm brings trouble when migrating to JLab 3?

Normally not. We can then bump the packages to 3.0.0.

When we adopt the new distribution system (which can be done in two steps), users will install the mamba-gator Python package 4.0, which will install the 3.0 extension as federated. And this shouldn't require a major bump for the Python package because JupyterLab 2 will ignore the federated extension placed in /share/jupyter/labextensions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintenance Maintenance task
Projects
None yet
Development

No branches or pull requests

3 participants