Publish a new release

[lawnsea]

We would like to use the nested partial blocks fix that landed from #1243. Can we cut a new release, please?

[nknapp]

From what I read in the last weeks, there is a urgent shortage of collaborators in this project.
@wycats, @kpdecker, @ErisDS: There is some documentation about performing the release. I have understood that @ErisDS attempted to start maintaining the 3.0-branch, but took a u-turn due to the amount of work this means.

My question is: Is the release-documentation up-to-date? Does the generator-release work for the master branch and just not for other branches? Or is there something missing and everything is more complicated? If it is just about performing some releases from time to time, I would offer to help. I probably don't know enough about the code to judge every single PR, but right know a single release would be sufficient.

This project is heavily used, with 10905 stars and 54,683 downloads a day, three maintainers seem to be a too few, especially if they are all occupied otherwise.

[ErisDS]

Doing a 3.0 release was too much work because all of the release tools assume you're releasing master, and I would have needed to release another branch.

As much as I have some familiarity with the code and a great deal of familiarity with the functionality of handlebars, yeoman and the gem-related steps of the release are quite unfamiliar tools to me. I also only have the ability to publish to npm, and not to rubygems.org.

In short, I'm here and could potentially do a release but only half of one 😁

[dpehrson]

I am currently blocked hard by #1243, but need the fix published in NPM.

I feel bad pinging this issue since I am not in a position to help solve the problem, but I am looking for guidance on whether I should cut my losses and move on to a different templating solution or if there is any likelihood that a release is pushed before the end of the month.

Thank you all for the hard (and usually thankless) work you do in maintaining a popular open source project, especially dealing with the community-related issues.

[lawnsea]

@ErisDS I guess my vote is to just do the npm release and deal with releasing the gem in another issue.

@wycats is there someone who can do the gem release? I would really like to get this fix out where we can actually use it.

[lawnsea]

To clarify my comment above, the npm release is what we need. We don't use the gem, AFAIK.

[dpehrson]

Just to relieve the pressure: This issue is no longer blocking us, we are going to switch to another templating solution.

Thanks to everyone for all their hard work over the years, I apologize that I can't be part of the solution to the problems facing the project at this time.

[stevenvachon]

"dependencies": {
  "handlebars": "wycats/handlebars.js"
}

[lawnsea]

Alright, y'all, @wycats is hooking me up with the permissions to do a release.

Next question: is this a major, minor, or patch release? Based on the currently unreleased commits on master, it seems like this will need to be a major release. Thoughts?

[ErisDS]

@lawnsea I didn't do the release because when I pointed out that there were breaking changes and this needs to be a major, I was informed by @wycats that he wasn't comfortable with some of the changes on master. @wycats & @mmun both said they didn't think there should be a major, implying that some changes needed reverting.

[lawnsea]

@ErisDS ok, thanks for that detail. As an alternative, I could cut a branch from 4.0.5 and land the non-controversial changes to that. Figuring out which changes are non-controversial will take some time, of course...

[mmun]

Would either of you mind making a list of the breaking changes? I'm not opposed to revving the major version in principle but I'd like to make sure the churn is worth it.

[lawnsea]

@mmun
some commits that look breaking to me:
3f77b82
63a0889
8517352
118836f

That list is likely not exhaustive. I doubt that many (any?) users are depending on the stuff removed from the compiler API. I'm more worried about the AMD build artifacts.

Given the number of downstream dependents that will automatically consume a minor or patch release, we should be very careful here.

[lawnsea]

Ok, I've confirmed that my patch for #1243 applies cleanly to v4.0.5 and that the tests pass. So, at @wycats suggestion, I propose we cut a release with those patches as v4.0.6 and have a longer discussion about what to do with the rest of master.

If there are bug fix commits on master that y'all think should go in v4.0.6, I'm fine with that as well.

[lawnsea]

Unless anyone objects, I'm going to create a 4.x branch from the v4.0.5 tag and open a PR with the bug fixes I propose to ship in v4.0.6.

[lawnsea]

Candidate release branch cut. Please take a look at #1270 and let me know if you want changes.

@wycats @ErisDS @mmun

[lawnsea]

Just published 4.0.6