org-journal
org-journal copied to clipboard
bastibe
rename master -> main and develop -> dev
hmm 🤔 do we really need a "dev" branch?
main/m***** -> melpa(-unstable) tags -> melpa-stable
In my professional work, I like to call the main branch "develop", and fork release branches from that. Which is roughly what the tags do for us. But "main" is probably today's industry standard, and a reasonable default.
Melpa is not especially meant to host unstable work, it is just the only means of distribution. Lots of people have said "Melpa Stable" should be removed, I won't get into the reasons, but once you realize that, then you see that the latest HEAD on "main" always has to be release-grade.
A dev branch lets you share experimental work with others, but if you tend to do all your work locally, a series of unstable commits that culminate in a stable commit before pushing to main, then you don't need a dev branch. Matter of personal work style.
I suppose one could make "develop" the default branch, and have an explicit :branch "main" or :branch "stable" in Melpa's recipe, so that people who install with Melpa get a stable version and people who clone the Git repo get "develop" by default.
Pull requests get accepted one by one, and generally leave main in a decent state. But there's value in collecting multiple smaller changes into a coordinated, version-numbered release.
If Melpa wants to ignore that work, and pull from main, they'll have to live with the churn. In my opinion, anyway.
It's not their responsibility, I think. You are already tagging releases, right? It's one extra step to push to a stable branch before tagging (and actually, by doing this you can omit the tagging step unless you use the tags for other purposes).
I mean. It's not as if MELPA is pulling from this repo without your request. Actually, you (or someone) submitted a recipe to MELPA to get them to start pulling, and that recipe is supposed to contain all the information they need to pull the right thing i.e. the version that's meant to be shipped to every John and Jane out there.
Currently the recipe looks like
(org-journal :fetcher github :repo "bastibe/org-journal")
You can change that to
(org-journal :fetcher github :repo "bastibe/org-journal"
:branch "stable")
The dev branch is indeed not necessary if feature/45, hotfix/1, rc/111, ???, and PR are used as the work style. I would prefer this work style, but to be honest, it requires at least two developers. PR reviews should always be done by another developer, in my opinion. Anyway, what do you guys think about this approach? It also clarifies which tasks are currently being worked on. However, the use of each branch prefix needs to be documented.
(org-journal :fetcher github :repo "bastibe/org-journal" :branch "stable")
I'm fine with the name stable for the main branch as well, as it makes the purpose of the branch clear.
Most PRs come from forks anyway, and therefore live on an external branch. If there are multiple concurrent developers, I like to prefix branch names with user names, i.e. bastibe/hotfix53, and casch-at/feature15. In our repo, this is mostly not the case, so simply hotfix53 or feature15 seems sufficient.
A dedicated stable branch sounds like a good idea. Essentially, we'd push every tagged version to the stable branch, and otherwise continue to work on main as before.
Bastian Bechtold @.***> writes:
Most PRs come from forks anyway, and therefore live on an external branch. If there are multiple concurrent developers, I like to prefix branch names with user names, i.e. bastibe/hotfix53, and casch-at/feature15. In our repo, this is mostly not the case, so simply hotfix53 or feature15 seems sufficient.
A dedicated stable branch sounds like a good idea. Essentially, we'd push every tagged version to the stable branch, and otherwise continue to work on main as before.
I like your naming convention bastibe/hotfix53, casch-at/feature15 or
hotfix53 for very small teams 👍.