Replies: 9 comments
-
|
good idea |
Beta Was this translation helpful? Give feedback.
-
|
hmm 🤔 do we really need a "dev" branch?
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 You can change that to |
Beta Was this translation helpful? Give feedback.
-
|
The dev branch is indeed not necessary if
I'm fine with the name |
Beta Was this translation helpful? Give feedback.
-
|
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. A dedicated stable branch sounds like a good idea. Essentially, we'd push every tagged version to the |
Beta Was this translation helpful? Give feedback.
-
|
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 👍.
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
All reactions