You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that @appleboy and @thinkerou are able to do releases. I would like to propose some changes in the process. Issue:
Things land on master for months before an official release. This causes a few issues,
People might wrongfully think new features or methods on master before a release are covered under the Semantic Versioning guarantees.
Releasing a PATCH will end up releasing code that was on master, waiting for the next MINOR release. This has a side effect of making us slow to release PATCH's because we know it's going to effect everything currently on master.
Proposal:
I would like to propose we cut a branch from master for the next MINOR release after we do a release then we merge all the new issues for that Milestone into that.
e.x: When we release 1.4.0 we create a 1.5.0 branch and take all new feature pull requests into the 1.5.0 branch. This way if we need to preform a PATCH release we can quickly merge a PATCH into master and then release 1.4.1, without having to bring in all the current work we are doing for 1.5.0. Once 1.5.0 closes all the milestones or meets it's deadline and becomes stable, It's merged into master and tagged 1.5.0 and we cut a 1.6.0 branch and start over.
Feedback welcome!
The text was updated successfully, but these errors were encountered:
@dmarkham thanks!
Now we should do the follow steps:
which one opening pull request need merge to gin1.4?
#1851 is I think the one we should start with.
MsgPack/protobuf/etc I wish we did differently but it's been on master for so long not released, and we are so close to a release :(. But (#1856) does seem way better idea now.
which one issue need complete and commit pull request and merge to gin1.4?
Sorry I do not understand the question. @thinkerou Are you able to join the gophers.slack.com slack channel? Will be nice to be able to ask you questions directly.
Now that @appleboy and @thinkerou are able to do releases. I would like to propose some changes in the process.
Issue:
People might wrongfully think new features or methods on master before a release are covered under the Semantic Versioning guarantees.
Releasing a
PATCH
will end up releasing code that was on master, waiting for the nextMINOR
release. This has a side effect of making us slow to releasePATCH
's because we know it's going to effect everything currently on master.Proposal:
I would like to propose we cut a branch from master for the next
MINOR
release after we do a release then we merge all the new issues for that Milestone into that.e.x: When we release
1.4.0
we create a1.5.0
branch and take all new feature pull requests into the1.5.0
branch. This way if we need to preform aPATCH
release we can quickly merge aPATCH
into master and then release1.4.1
, without having to bring in all the current work we are doing for1.5.0
. Once1.5.0
closes all the milestones or meets it's deadline and becomes stable, It's merged into master and tagged1.5.0
and we cut a1.6.0
branch and start over.Feedback welcome!
The text was updated successfully, but these errors were encountered: