search

damianavila / RISE

RISE: "Live" Reveal.js Jupyter/IPython Slideshow Extension
Other
3.68k stars 416 forks source link

roadmap #491

Open parmentelat opened 5 years ago

parmentelat commented 5 years ago

because things tend to have become a bit shuffled up recently, here's a quick braindump

5.5

5.6

There are also 2 rather important changes in the git tree on top of 5.6:

branch split-rise-reveal is about #490

branch jlab-redeux is about the jupyterlab extension

In terms of numbering and releasing, I can see several options, but they all start with:

STEP 1 issuing 5.6.0 as essentially 5.6.0-dev4 + bugfixes if needed (I'm quite happy with it at this point, but may have not tested the complete feature set)

Let me remind that everyone can give this a try with

pip install -U --pre rise

and reports - bug reports or OK reports - are always welcome :)

EDIT 2019/11: release 5.6 is now officially published, the --pre option is no longer required

damianavila commented 5 years ago

5.5

Perfect! Thanks! I have redirected the root of the docs page to the maint-5.5 branch for now... so we can show the proper changelog. Additionally, I can confirm conda packages are available trough conda-forge as well.

damianavila commented 5 years ago

STEP 1 issuing 5.6.0 as essentially 5.6.0-dev4 + bugfixes if needed (I'm quite happy with it at this point, but may have not tested the complete feature set)

I agree with that, let's have the beta out there for 2 weeks. So we give people (and me :wink:) time to test and play with it (reveal-3.8 is a big change, so let's give the bugs enough time to surface). Then, we can release it if we do not have any blocker.

damianavila commented 5 years ago

but building and packaging must be double-checked because that can easily have suffered in the move also the way the rise-reveal npm package exposes its contents - namely through an export subdir is maybe not exactly elegant; later on I read about webpack that uses the dist/ convention instead, it's the same intention, but if anyone has something to say about my choice it would be good to speak up soon :)

Now I have a PR to review #490 :wink: so I will provide my feedback on it pretty soon.

damianavila commented 5 years ago

nothing much is working at this point but we start to understand how we'd fit into the landscape this branch right now sits on top of the split-rise-reveal one, because it leverages of course the split

Great, it is the next big thing... we should discuss later how we are versioning classic and lab extensions. but let's focus first on making the labextension a real thing!

damianavila commented 4 years ago

RISE 5.6.0 is available in PyPI (https://pypi.org/project/rise/5.6.0/) and it is being built in conda-forge: https://github.com/conda-forge/rise-feedstock/pull/26.

After confirming everything is OK, I will be removing the maint-5.5 branch and reporting the release on the corresponding issues.

Finally, I will make a blog post with the ANN.

cc @parmentelat

parmentelat commented 4 years ago

short update

I have made a pass to publish 5.7.0-dev releases; it took an awkward few screwed up attempts to get everything right wrt github/readthedocs/pypi with the new sources layout, but I'm rather happy with the result (including proper markdown rendering on pypi) , so we can now instruct adventurous people to install that 5.7 release using the usual

pip install -U --pre rise

I have tidied up the master branch as bast I could, at that point I believe all the changes made in maintenance branches are in there

as a side note @damianavila, I don't seem to have management rights on pypi; I can publish, but I cannot clean up behind me, so I'd appreciate if you could spend 5 minutes removing useless dev releases there (or give me management access if you find out how to do that :)

also @damianavila, would you mind writing down a short update on your end regarding jlab ?

damianavila commented 4 years ago

I have tidied up the master branch as bast I could, at that point I believe all the changes made in maintenance branches are in there

Thanks for all that work! Do you think we should release 5.7.0 anytime soon? I see you released several dev versions so maybe it is a good time now...

as a side note @damianavila, I don't seem to have management rights on pypi; I can publish, but I cannot clean up behind me, so I'd appreciate if you could spend 5 minutes removing useless dev releases there (or give me management access if you find out how to do that :)

That's weird... You have a maintainer role there... that, it seems it is not enough to remove package. So I made you an owner as well, you should be able to remove packages now. Btw, I am not sure if we want to remove dev packages... probably yes. If you want to try your new powers, that would be nice to check everything is set up properly.

also @damianavila, would you mind writing down a short update on your end regarding jlab ?

I will try to do that this weekend on the corresponding issue, but I will leave a link here as well.

parmentelat commented 4 years ago

yes I think we should issue a 5.7 as soon as it has gone through your testing, as it is mostly equivalent to 5.6 in terms of functionality but has the new sources layout in place

permissions all right and cleanup done; thanks
I am keeping only the last dev version online - we still have tags in the git repo for those dev versions

damianavila commented 4 years ago

yes I think we should issue a 5.7 as soon as it has gone through your testing, as it is mostly equivalent to 5.6 in terms of functionality but has the new sources layout in place

OK, planning to make that release toward the end on Jun.

permissions all right and cleanup done; thanks

Wonderful

I am keeping only the last dev version online - we still have tags in the git repo for those dev versions

Make sense!

parmentelat commented 4 years ago

just released 5.7 on pypi

@damianavila please push onto conda if needed

damianavila commented 4 years ago

Perfect, I will make the conda packaging tomorrow! Thanks @parmentelat!

dhirschfeld commented 4 years ago

It doesn't seem like there's a corresponding tag for the release?

parmentelat commented 4 years ago

oops sorry, forgot to push the tag, it's done now

damianavila commented 4 years ago

Perfect, I will make the conda packaging tomorrow!

Thanks to conda-forge, it seems we had a bot doing the whole conda stuff for us: https://github.com/conda-forge/rise-feedstock/pull/32.

And I can see the package here: https://anaconda.org/conda-forge/rise/files?version=5.7.0 which is lovely :wink:

damianavila commented 4 years ago

I will make an ANN soon and after a few weeks we can release a 5.7.1 or 5.8.0, I would say by the end of Nov unless we have something urgent to release before that timeframe.

damianavila commented 4 years ago

OK, the buttons disappearing so quickly need a 5.7.1, IMHO. Otherwise, we are getting a lot of reports...

damianavila commented 4 years ago

Looking into this now...

damianavila commented 4 years ago

@parmentelat now master and stable are even. Let's use stable for maintenance purposes (I mean let branch out from stable for maint bugfixes and push back to stable with PRs) and master for cutting edge stuff (ie. jupyterlab ext + other classic ext improvements if we decide to keep adding stuff there - that's another discussion).

damianavila commented 4 years ago

Btw, I tested 5.7.1.dev0 and it seems to be working as expected. Planning to do the release tomorrow unless @parmentelat stop me :wink:

damianavila commented 4 years ago

OK, 5.7.1 was build and pushed to PyPI. Doing the conda packaging, docs, and ANN tomorrow...

damianavila commented 4 years ago

@parmentelat can you give access to the test.pypi stuff... I was not able to push to the test server (I tested installing from the local package). Thanks!

parmentelat commented 4 years ago

hi Damian, I just invited you

damianavila commented 4 years ago

Conda packaging is ready: https://github.com/conda-forge/rise-feedstock/pull/33

damianavila commented 4 years ago

It seems 2 packages are missing from anaconda.org... asking on the linked PR.

damianavila commented 4 years ago

The CI jobs on conda-forge were restarted and the missing packages are live now.

damianavila commented 4 years ago

Docs updated and ANNs (on several channels) done: https://damianavila.github.io/blog/posts/rise-571-is-out.html

damianavila commented 4 years ago

FYI, @parmentelat we have three important branches now:

The jupyterlab_extension is my original branch and I merged there your jlab-redeux so we keep those additional commits you did. I will unify/integrate both jupyterlab and jlab directories with some local stuff I did some weeks ago into a new and shiny lab directory and continue the labextension development there...

damianavila commented 4 years ago

OK, we now have just one lab directory in the jupyterlab_extension branch:

https://github.com/damianavila/RISE/tree/jupyterlab_extension/lab

This is using the patched rise-reveal we use for classic! (using the new layout, thanks for working on that @parmentelat !)

parmentelat commented 3 years ago

Hi @damianavila

I failed to react at the time, but it looks like the naming is a little confusing; what's the intention with stable and master then ?

specifically, should contributors file their PRs against master or stable ?

there's been in particular #586, which I merged right away, but I had not noticed it was against stable, and as a result the repo is not very readable IMHO

(there's this rather usual convention to put new stuff on a devel branch, and once happy to merge devel onto master; but in that convention, master is the stable branch...)

please instruct how you want to proceed;

damianavila commented 3 years ago

OK, maybe it is actually confusing... let me see if this map helps...

master (damian) > devel (thierry and maybe the rest of the world) stable (damian) > master (thierry and maybe the rest of the world)

My idea was to keep master as the cutting edge and stable as the code you branch out to generate the maint branches and push the docs fixes.

damianavila commented 3 years ago

@parmentelat, happy to change the convention is this is confusing for people.

parmentelat commented 3 years ago

yes as I said I am more used to the convention about using devel for cutting edge and master for stable but now this is your code, and it's only a convention I'd just suggest of you want to stick with the (master, stable) one, to then spell it out somewhere in the devel doc feel free to adjust the naming as ytou see fit

damianavila commented 3 years ago

I'd just suggest of you want to stick with the (master, stable) one, to then spell it out somewhere in the devel doc

That's a good suggestion!

feel free to adjust the naming as ytou see fit

Yep, I may adjust depending on how others (besides us) have (or not) problems with this convention.

Nice to talk with you again, btw :wink: