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

Suggest: use releases instead of branches #25

Open
richelbilderbeek opened this issue Sep 25, 2023 · 2 comments
Open

Suggest: use releases instead of branches #25

richelbilderbeek opened this issue Sep 25, 2023 · 2 comments

Comments

@richelbilderbeek
Copy link
Member

Currently, this repo has different branches for different iterations of the course.

As this was the first time I saw the use of branches for different versions, I googled and could not find a good reason why one wants to do this; the majority of the advices I read (among other here) recommend to use release versions.

I suggest to follow standard git practices and use versions.

I volunteer to tag each branch with a version.

@richelbilderbeek
Copy link
Member Author

Note that using GitHub Pages will work out-of-the-box if master is the most recent version of the course :-)

@richelbilderbeek
Copy link
Member Author

Here is an argument why to use branches by @ninanorgren:

We don't use github pages anymore, everything is moved to Canvas, where the most recent courses are. We should probably just redirect on the gh-page to the canvas page. What we should also do is create a "startpage" on Canvas that lists all the previous and upcoming instances of the course. For which branch to use, we should not merge anything into master, but keep them separate by year. Otherwise all integrations will break and it will not be possible to access old instances

I wonder:

  • 'otherwise all integrations will break': how much is that?
  • 'it will not be possible to access old instances': how is this meant? One can browse earlier releases (see an example repo). And, due to git, one can always go back in time anyways.

I assume this will be more clear to me in the future, i.e. why a non-standard repo setup is used here.

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

No branches or pull requests

1 participant