search

go-siris / siris

DEPRECATED: The community driven fork of Iris. The fastest web framework for Golang!
Other
142 stars 16 forks source link

TEAM: Release-Management #10

Closed Dexus closed 7 years ago

Dexus commented 7 years ago

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?

Andersbiha commented 7 years ago

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.

Dexus commented 7 years ago

So what is the best way to release for gopkg.in and github.com? To use everywhere as import "gopkg.in/siris.v7"?

Dexus commented 7 years ago

With v8 I would like to change github.com/go-siris/siris to gopkg.in/siris.v8 Any thoughts?

godofdream commented 7 years ago

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

Dexus commented 7 years ago

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.

godofdream commented 7 years ago

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.

Allendar commented 7 years ago

Following up on https://github.com/go-siris/siris/issues/26 I think the changes are so minor that a 7.4 would sound more reasonable. Otherwise we end up like Firefox having 53 versions. It doesn't seem to signify it's purpose anymore to go so fast.