Mark this repo as archived

[telamonian]

Now that the TOC extension is part of jupyterlab core, we should probably mark this repo as archived, and also add some helpful text for new/latecomers (eg "If you have jlab v<x, install this extension. Otherwise, TOC is already built into jlab" or whatever).

Pinging the people who actually worked on this extension:

@kgryte
@marthacryan
@jasongrout
@lresende

[kgryte]

I haven't kept up with work in core, so I'm not sure if the core implementation has feature parity. There was talk some time ago that this extension may need to be refactored so that things like collapsible headings can be implemented on top of core. In which case, some development could still happen on this repo or maybe that could now all happen in core. Others invariably know more than I.

[telamonian]

some development could still happen on this repo

That kind of splitting of issues and codebase is exactly what I want to avoid. The TOC extension included in core is now the canonical one, that's where all new work should go

or maybe that could now all happen in core

yes, please

[marthacryan]

I support archiving this - as mentioned above, it's better to just direct all changes to the core extension now. Not sure I have the permissions to archive it, but I'll add a PR to add the text to the README about versions / etc.

[ellisonbg]

I think it makes sense to archive this repo and direct people to core.

…

On Fri, Nov 20, 2020 at 6:47 AM Martha Cryan ***@***.***> wrote: I support archiving this - as mentioned above, it's better to just direct all changes to the core extension now. Not sure I have the permissions to archive it, but I'll add a PR to add the text to the README about versions / etc. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#158 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGXUFUMAKUM3D2IAMJG2DSQZ6QTANCNFSM4T2V4ULA> .

-- Brian E. Granger Principal Technical Program Manager, AWS AI Platform (brgrange@amazon.com) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[jasongrout]

This is saying that there will be no more releases of ToC for jlab 2.x, even backports of things from the core 3.0 extension. Is that okay with everyone? Especially given that we still haven't released 3.0 and 2.x is still the current version.

[jasongrout]

It makes me a bit nervous to archive something that is still the stable released version, without the next version being released yet

[lresende]

How about we clarify the direction we are taking in the README, and wait a little bit for the archive.
Having said that, I don't have access to archive it.

[jasongrout]

How about we clarify the direction we are taking in the README, and wait a little bit for the archive.

That seems safer to me. If there is a huge security issue that needs a patch in the jlab 2.x plugin, you might still want to do a patch release. I would say archive the repo when the 2.x plugin is no longer supported.

[marthacryan]

@jasongrout Do you think we should be backporting PR's from the core 3.0 extension? I haven't been doing that for any of my PR's in the main JL repo, but I can do that if you want. Good point that security releases could be necessary though so we should wait until 2.x is no longer supported to archive. I can update the README to explain it correctly

[jasongrout]

Do you think we should be backporting PR's from the core 3.0 extension?

That's up to the maintainers here to make that decision, of course (i.e., including you :), but my feeling is that just backporting security fixes is perfectly fine.