search

valum-framework / valum

Web micro-framework written in Vala
https://valum-framework.readthedocs.io/en/latest/
GNU Lesser General Public License v3.0
226 stars 23 forks source link

Some documentation edits #127

Closed Bob131 closed 9 years ago

Bob131 commented 9 years ago

Just fixing some typos and such

arteymix commented 9 years ago

You might have other edits, so I'll keep that open until you feel the docs is good enough ;)

Bob131 commented 9 years ago

Ah, okay. Also, quick commit style q: Do you prefer to have multiple commits that can be squashed in a PR, or is amend+force push preferred?

arteymix commented 9 years ago

In this case, as you are improving the documentation, a single commit is sufficient.

More generally, each commit should focus on a particular feature or improvement. I typically squash fixes with git rebase -i on my local commits and push them when I feel they're good to go public. It's easier to revert particular feature this way and makes the history more understandable.

By the way, you manage this PR so feel free to rewrite the history as it suits you.

One last word, I keep two trunks: master and next that targets the next hotfix and minor release respectively. Features should be submitted on the latter.

arteymix commented 9 years ago

In fact I wonder if next is really relevant.. Feature submissions can just wait until the trunk moves to the next minor release. Hotfixing a specific release can simply be done by deriving its tag and releasing another tag.

Bob131 commented 9 years ago

The version of the popular distilled wisdom on branch management in my head was that master should contain the latest code that builds and passes tests with tags for releases and branches for features. But if I'm expert in anything, it's not codebase management