Changelog for v0.17.0

[Tapppi]

Do you want to request a feature or report a bug?
Feature, with a sprinkle of human error or delay.

What is the current behavior?
No changelog with v0.17.0 release. Cannot find a definitive changelog anywhere.

What is the expected behavior?
There should be a changelog accompanied in the release.

There should be an updated changelog available somewhere, e.g. CHANGELOG.md in github or a changelog page in the documentation.

Have you considered automated changelog generation?

[danielkcz]

In my opinion it's very rare to see changelog for projects this heavily under development and with zero major version. I don't even think it's important to have that till we reach the point where Yarn at least works on level of NPM without any critical issues.

[wyze]

You can get a basic idea from here: v0.16.1...v0.17.0

Which is basically what was posted on the release for 0.16.0.

[Tapppi]

IMHO at least recording breaking changes in a changelog is crucial to allow people to upgrade without dwelling into a huge commit list, since its a big project.

Regardless of heavy development, a lot of people will be using yarn in e.g. CI, and having to update with a "well test it and see if it works" mentality every update is ridiculous when you can just record breaking changes in commits and autogenerate a changelog based on them. Or just write them up in a release.

But it's up to the yarn team anyway, just my two cents on the subject.

[sysadmiral]

I beg to differ @FredyC - terraform is under heavy development yet they seem to be fine with maintaining a changelog - https://github.com/hashicorp/terraform/blob/v0.7.10/CHANGELOG.md

It should be easy to see what changed on the website rather than having to go to github and diffing two versions. Some devs may never go to github and just "use" frontend tools so they should be able to see what changed from the main yarn site. (IMHO)

[danielkcz]

@sysadmiral Those are two quite different projects. I mean Yarn needs to catch up on NPM first to be even considered usable. I don't really care for a list of changes as long as I cannot use Yarn for my big project. I am not sure why people would even consider using Yarn in CI already, that's quite a step into a darkness.

[random-stranger]

@FredyC you don't need it, that's fine. If you are not sure about using it - don't use it.

Another devs, who use it everyday, need this and even a simple changelog helps to quickly view, what has changed, what bugs were fixed instead of diffing the commits.

Popular projects, that people tend to use every day, must have a changelog.

[Tapppi]

@FredyC yarn is actually very much so usable with only a few workarounds, I sped up a few builds I tested it on in CI by over 50% after fiddling around 10 mins with the workarounds. And you can be sure that especially people with no complex private package shenanigans etc. will be using yarn extensively in CI. The majority of devs don't use npm's more advanced/obscure features that yarn doesn't support yet.

[danielkcz]

@Tapppi Sadly sticking to only official releases of packages is not possible as people tend to leave packages unmaintained or simply don't want to change package in some way that might be more helpful in certain cases. That leads to creating forks and relying on installing packages from other locations. Calling this as a shenanigans is kinda short sighted in my opinion.

Not even mentioning that in same cases it's not even working for regular packages: #992 (do you have workaround for that?)

I guess that changelog can be handy, but at current state of development I would say it's a waste of energy for the team. If someone is interested in changes, check out commits as mentioned.

[Tapppi]

@FredyC I was talking about the majority, and the majority don't use private registries/packages for dealing with unmaintained packages, but fork as you said, making it accessible from the npm registry. Regardless, that is besides my point, and is getting off-topic fast.

Just because you don't see something as fitting your use case, doesn't mean it doesn't fit others'. You are making broad generalisations based on what YOU need, and what YOU feel is right for YOUR team. Effectively, you are saying that other peoples' use cases should not be considered important enough to warrant simple and low-effort helping hand during a possibly complex operation such as a breaking update.

If you are taking issue with changelog maintenance taking time from the team, I don't think you realise this is something that can be automated to the point of writing git commits with just a BREAKING CHANGES: footer for breaking changes or structured commits for all feat/fix/perf/etc. changes and a single command on release time (with e.g. conventional-changelog tools). That should not slow down the work needed to get yarn to a point where your team can use it too.

P.S. Regarding #992, you could probably write a oneliner "postinstall" script to fix the permissions after every install.

[danielkcz]

Just because you don't see something as fitting your use case, doesn't mean it doesn't fit others'. You are making broad generalisations based on what YOU need, and what YOU feel is right for YOUR team.

That can be said both ways. I've only expressed my opinion so far...

You are forgetting that this is an open source. People developing it don't owe you anything really and you can just as easily go and make that changelog by yourself for others to use it. It's nothing secret and doesn't really require knowledge of the code. I feel rather sick of people expecting some special services while they are not really willing to help out or at least pay for it.

I would say focusing on automated changelog is ridiculous at the point when there isn't even automated process of releasing new version.

[IanVS]

I'll just leave this here. There are some good points. http://keepachangelog.com/en/0.3.0/

[Tapppi]

@IanVS
Whole heartedly agree with the content of the link, except with some conventions 😉

---

@FredyC

You are forgetting that this is an open source. People developing it don't owe you anything really and you can just as easily go and make that changelog by yourself for others to use it.

I certainly am not forgetting that this is OSS. I have not, at least intentionally, indicated that anyone owes me anything. I have made a case for the usefulness of a changelog to a big open source project such as yarn, which seems to have been echoed by plenty of other people.

Yes, I could go "write a changelog" based on the git commit logs, but that makes zero sense and is wastefully time consuming for someone that wasn't involved in the release. The changelog generation should simply be automated, like releases, with minimal human intervention only when needed, e.g. during writing of commit messages with breaking changes.

I would say focusing on automated changelog is ridiculous at the point when there isn't even automated process of releasing new version.

Changelogs are in my opinion a fundamental part of releases, and as such a part of the automated release process. There have been plenty of reasons given for this already here and elsewhere.

---

I feel rather sick of people expecting some special services while they are not really willing to help out or at least pay for it.

And finally to answer your criticism of me opening an issue to discuss what I see as an issue:

There have been zero demands or discussions about who would do work on this. I am not requesting any "special services". As you have gladly pointed out, this is open source, and someone willing will have to pick it up. OSS allows people to develop and use software much more effectively. I fail to see why you would not want a feature that has the one goal of making continuous use of the software easier?

I am part of the https://github.com/conventional-changelog/ org and would gladly help out in sorting out an effective changelog solution for yarn. I'm not well enough acquainted with the team, release process and codebase to just go do it alone, lest it take more time and resources than necessary, while possibly not even going in the right direction.

Frankly, I do not understand why you think this qualifies as requesting some "special services" any more than other usability issues. I have, continue to and intend to contribute to as many OSS projects as I have time. If you want to continue discussing my "flawed" preconceptions about OSS contributions, you are free to contact me personally, but I think this issue is not the right forum to continue such a discussion. I apologise to any other readers about the wall of text. 😞

[bestander]

Hey everyone, I was planning to release a Changelog and add it to the 0.17.0 release.
But I was distracted by a lot of regressions in 0.17.0, tracking them in #1859.

Also there was a big break in another OSS project yesterday, so I was spread thin.
Don't worry, the Changelog is coming, I am planning to do it today.
If anyone wants to contribute and write a Changelog for everyone, that would be always welcome.

I hope in the next few weeks we will stabilize the releases, get more tests and more community members will step up with project maintenance.

I'll close the issue but keep the conversation going.

[mrandre]

I just wanted to drop my opinion that it is very questionable to me to make a release that is used by many people with no explanation of what is happening. I am frankly baffled that this is a thing. How am I supposed to reason about this? I can appreciate that team members are deeply aware of every single thing that is happening, but out here, where I just want my problems solved, it is frankly bizarre. Like if Apple released a new laptop, but refused to tell us anything about it. That would be crazy, right?

It seems to me a release can wait on such an explanation, and its lack should be a blocker.

[mrandre]

For what it is worth, it would make a big difference just to say "No release notes yet, but they are coming."

[leikind]

A changelog with a very short description of major changes would only add value to the project.