You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GitHub builds Jekyll sites from master branch from the repository specified the remote_theme property in _config.yml.
For that reason, master should always be the stable, released version of jekyll-theme-ed2 (once we get to our initial public-release versions, anyway).
And also for that reason, I propose that we maintain a next branch for jekyll-theme-ed2, which should be the base branch for all pull requests and other pre-release work.
GitHub builds Jekyll sites from
master
branch from the repository specified theremote_theme
property in_config.yml
.For that reason,
master
should always be the stable, released version of jekyll-theme-ed2 (once we get to our initial public-release versions, anyway).And also for that reason, I propose that we maintain a
next
branch for jekyll-theme-ed2, which should be the base branch for all pull requests and other pre-release work.Commits from
next
would then only appear onmaster
as a part of a formal version release, whose initial procedures I've documented here: https://github.com/minicomp/jekyll-theme-ed2/wiki/Creating-releasesAssuming the idea of maintaining
master
andnext
branches this way sounds like a good idea, I will update those documented steps accordingly.The text was updated successfully, but these errors were encountered: