suggestion: tag releases about goji HOT 9 CLOSED

@hasryan—The master branch is always stable. I've also just published a 1.0 release, in case that's more your cup of tea.

from goji.

I haven't had the courage to cut a release yet (maybe I ought to suck it up and do it), but when I do I'll be sure to tag it :)

from goji.

I hope the version/tagging will help developer to resolve any dependencies issue - tag or semantic version is much easier to remember. Thanks!

Sent from my iPhone

On 4 Aug 2014, at 19:15, Carl Jackson [email protected] wrote:

I haven't had the courage to cut a release yet (maybe I ought to suck it up and do it), but when I do I'll be sure to tag it :)

—
Reply to this email directly or view it on GitHub.

from goji.

+1

I'd like to see that. Currently it seems to be pretty stable, so maybe it is a good time to cut first release?

from goji.

Yeah, I think we're probably approaching API stability (see also #14) and it's probably about time to tag a release.

Things on my short list of things to do, likely before then:

• Change how * works in string patterns. My current plan is to expose a special "*" URLParam which binds the remainder of the route, and maybe to do something special with /* at the end (i.e., to include a leading "/" on such a string)
• Update graceful to use Go 1.3's new ConnState API, although I'm running into some difficulties there (https://groups.google.com/forum/#!topic/golang-nuts/Xi8yjBGWfCQ). As far as API goes, this will probably entail cutting back on API surface area to make the package HTTP only.
• Tear out some more of the "standard" middleware and put them in separate packages.

from goji.

Based on issue #67 it would be nice if you could tag Go1.2 to make it easy for AppEngine users when they use goapp get.

When checking out or updating a package, get looks for a branch or tag that matches the locally installed version of Go. The most important rule is that if the local installation is running version "go1", get searches for a branch or tag named "go1". If no such version exists it retrieves the most recent version of the package.

from goji.

Alright, I've made the last (fairly small) breaking API change I have had planned, and have tagged v0.8 (https://github.com/zenazn/goji/releases/tag/v0.8).

Since I just made these changes, I'm going to let this code sit for a while before tagging v1.0, but I don't think we're very far off from a release with hard API stability guarantees. :)

@lesv — I don't really want to use version branches to support AppEngine since it causes divergent history (I maintained a go1.3 branch for a while and it was pretty miserable). Since fixing the issue in #67 doesn't seem to be particularly urgent for the AppEngine folks, I'm going to look into a workaround on the Goji side.

from goji.

Are there plans to make additional releases? Last one was 0.9 in Jan 2015. If not, should the master branch always be considered stable?

from goji.

@zenazn thank you! I do like to use tagged releases when available.

from goji.