TEAM: Release-Management
Dexus opened this issue · comments
Hi,
I would like to know how we would like to do the release managment?
I prefer a own branch "release" where we release the new versions.
To release we should use gopkg.in/siris.vX like gopkg.in/siris.v7.
In the master branch we only work under github.com/go-siris/siris.
In master is it allowed to push multiple commits in a PR and should be squashed merged or follow the rebased infos like (https://github.com/haraka/Haraka/wiki/Contributing), but in release it is only allowed to do squashed commits since last release.
So, what do you think?
From my point of view i think we should start tracking minor and possibly even patch releases in gopkg.in and github as well.
Suddenly loosing releases have been a big troublemaker in the past.
Any development should happen in feature branches merged to dev from PR's and onto the next release branch with --no-ff so we can keep the history clear.
The master should only contain the changes of the latest fully published release.
On branches with more than a couple commits, it's usually best to squash the commits (condense them into one) before submitting the change(s) as a PR. Notable exceptions to the single commit guideline are:
where there are multiple logical changes, put each in a commit (easier to review and revert)
whitespace changes belong in their own commit
no-op code refactoring is separate from functional changes
Following the guideline in your link above regarding squashing seems like the way to handle commits in the feature branches.
So what is the best way to release for gopkg.in and github.com?
To use everywhere as import "gopkg.in/siris.v7"?
With v8 I would like to change github.com/go-siris/siris to gopkg.in/siris.v8
Any thoughts?
Do we need a version bump? I would use v8 only on breaking changes and otherwise v7.
changing to gopkg.in/siris.v7 sounds reasonable
The change to with v8 will not break currently installations, thats my thought of it.
v8 should be the first own future "SIRIS" release because we change the API I think for the QUIC Support a bit. Maybe not, I don't know yet.
We could Make the Quic-Support configurable using the SIRIs-Config, so we don't need to change the API.
Everytime we change the API a smooth update is impossible.
