Hello,
I know Hugo is not critical app and it generates static content so no problem using dev-version, but just wonder if you have considered to have somewhat shorter release cycle, at least while it’s < 1.0? 
I keep planning on having a 2-3 month release cycle and it never seems to happen. I’d certainly like it to be much sooner than it’s been. We should try for a 6 - 8 week cycle until 1.0.
IMHO, this can be solved quiote simply: Create patch level releases.
I believe currently, releases are few and far between because they only get done whenever the major and minor version numbers get bumped. If Hugo were to bump patch numbers, then releases could happen more frequently, without compromising on the principles that have applied thus far for the minor version number releases.
This would:
- Address the problem of infrequent releases
- Allow users who simply want to use the built binary to be more up to date (users who do not want to install git or golang and build from source)
- Have a more human readable way to pinpoint regressions - git commit hashes vs version numbers
patch releases would be nice to get things out asap when they contain fixes like the “Fixed a lot of Windows-related path issues” in the release log of v0.13.
There is currently some work involved in making a release, and until that is scripted into one button, I guess 6-8 weeks makes sense.
0.13 has been crazy with its 5 or something months.
What’s the status on 0.14?
Close.
EDIT IN: Maybe soon. It all depends on the chef. He is a busy bee these days. Good for him. Not optimal for you.
+1 for Semver. I freakin’ love this SSG so far after only a few days of playing with it. Any thoughts on an idea/target date for 1.0 @spf13? Thanks.
We should collectively make a list of what needs to happen for 1.0.
I’d love to get on a more frequent release schedule. I’d like to have more people play roles in the Hugo dev team and one role would be release captain (which could be a revolving one).
My vote is to have releases ever 6 - 8 weeks.
Independent of those releases we should make a list of all items we want before 1.0 locks in things and once all of those items are complete the next release should be 1.0.
1 Like
What’s the magic button that @bep mentioned earlier that would help speed up the tempo on releases?
- A release captain (If it’s me it will go on too long. I’ve proven I can’t be trusted to be responsible for timely releases)
- Me to make it so someone else can release. Right now I’m very close. There’s only one step that I’m needed for and that’s switching the site to the new docs branch.
Any volunteers for 0.16 release captain?
The magic button, which isn’t a “solve-it-all” button, was to automate many of the tasks around releases – so they become “cheaper” to do, and as such will happen more often. As it is now, having serious bugs making it into a release is scary, cause you cannot get a fix out in the next 6 months.
We got CircleCI in place, they do support bulding multiplatform Go binaries.