Comments (9)
@parente, thoughts?
from jupyterlab_xkcd.
I started to use branches at certain commit points originally, but quickly found that it was really hard to follow the history as a tutorial reader. I went to tags as a stop gap and started rewriting master just to get a first version prepped with a reasonable history.
Going forward, I'd like to see the clean git history retained for readability, but agree we need a way to version what's here to match JupyterLab versions at a minimum, if not tutorial versions. I'm not sure how to fit that with a traditional PR workflow.
from jupyterlab_xkcd.
Okay, let's assume a single branch. What we could do is have a "rotating" set of commits that are scoped with the appropriate version (e.g. v0.27-01-foo
). After a release of JupyterLab, we create a new PR against this repo. We start from the markdown (or notebook), updating both the document and this repo, creating the new tags along the way. We merge this PR first, so the links in the tutorial document are live, and then merge the JupyterLab PR.
from jupyterlab_xkcd.
Maybe this is what you were suggesting to start and I just figured it out: how about having a long-lived branch per jupyterlab release (e.g., v0.27
) with tags like you suggest on that branch (v0.27-01-foo
)? If there are mistakes on those branches, instead of making PRs, we can fix by rewriting history to keep the flow clean. It won't make contributing all that simple, but the tutorial is really the system of record here and the code repo is just a reference.
I think GitHub lets you choose which branch appears as the default when users land on the project page. We could flip to the one matching the latest stable release of JupyterLab, or the latest branch that remains compatible.
from jupyterlab_xkcd.
Ah, so the branch history has only the commits referenced in the tutorial?
from jupyterlab_xkcd.
Yes. Just an idea. Why do you think?
from jupyterlab_xkcd.
Mobile. Sorry. What, not why.
from jupyterlab_xkcd.
Okay, so I'll create a branch for 0.28 using git checkout --orphan 0.28
and use the tagging pattern. Then we point GitHub at that branch as a default (I've seen other repos change the default branch).
from jupyterlab_xkcd.
Thanks. Let's see how it goes. If it turns into too much work, we can find another way.
Let me know if I can help at all.
from jupyterlab_xkcd.
Related Issues (6)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jupyterlab_xkcd.