It's been more than a year since https://github.com/gulpjs/gulp/issues/1486, which is a bit sad.
We are using gulp v4 in our day-to-day development for 10 months already, since @GiedriusGrabauskas wrote the typings for the v4 here:
https://github.com/types/npm-gulp/tree/master/4.0.0-alpha.2
It would be great to get some progress-update, should we still expect the version or will it die eventually? 馃槥
Not dying, but we have jobs and lives - it will get finished, but nobody seems keen on helping (open source!) so it has to take a back seat to our real jobs that provide food and a roof to live under.
Also, the 3.x branch works fine - thousands of companies and hundreds of thousands of people still use it every day. 4.x isn't an emergency that needs to be solved ASAP - it's minor improvements, baking in some things you can already do into core.
After the 4.0 release the project probably won't need any more major breaking releases. Sometimes projects are just feature complete and don't need to be rewritten every 3 months according to the latest trends. I'm not sure why it bugs people so much that we don't thrash our API every couple of months, and that we promote stability over complexity. It's a task runner, with some opinions about how file transformation works (vinyl) - not building a rocket ship here.
Amen @contra
@phated, @sgen, @contra , thank you for the reply.
I didn't want to sound harsh, nor that was a rant, just wanted to check 馃憤
The work you did and are still doing is amazing and, as you said, is being used by thousands and thousands of people.
At the moment our company is open-sourcing multiple packages into @SimplrJS and I'm thinking about gulp v4 as a project we would like to help with next.
As it is almost done, if we find some time to fit our schedule, we will look into joining forces as we like gulp very much. If the schedule for release you see is in 2-4 weeks, we might miss the train here, but if it's 2-3 months, we should be able to help.
I believe our team is experienced enough and is not frightened by low-level code (as low level as JS can get). I'll look into issues that are still open soon.
If you found half an hour of your time any time soon and could write down a list of what has to be done, because it spans multiple projects and repositories, we could track the WIP easier.
Pardon me if the list already exists, but what I found was #1604 where you talk about vinyl-fs v3, for which I did not find a branch in its repository. And this is why listing everything in a one place would really help.
And again, I wanna shout out to you guys for an amazing work you do! 馃憦 鉂わ笍
Thanks for the thorough reply. I actually have a organization level project created (I think I need to add a few of the newer issues).
For reference (now that I'm at my computer): https://github.com/orgs/gulpjs/projects/1
Hmm... I get 404. Might be because I'm not in organization.
Wow, that's frustrating. Not sure the best way to solve it (thought about taking a screenshot but our lists are too long).
Well, repository projects are public, organizational ones are not.
https://github.com/SimplrJS/simplr-forms/projects/1
A sample public project on a repository.
Repository projects wouldn't solve discovery across repos that people seem to complain about.
The (current) best way to find the open issues that need help is by using github's global search: https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+org%3Agulpjs+label%3A%22help+wanted%22+
I see. It's a pity that the project is not accessible though.
I will get back to the issues if/when the team will have time.
@DovydasNavickas I took a few hours today to hack out a Organization Projects View for gulp. Check it out at http://107.170.66.219/425353
@phated, this is nice! I guess Docs and TODO are ad-hoc and most important ones, right?
And it would be super nice if clicking on an issue would link to an actual issue and not API 馃 馃槃
TODO, In progress (many need help) and Docs (not critical for the next tag on npm). Thanks for catching my linking, I've fixed it.
Is there anything I can do to help you all with documentation? I am seriously loving Gulp 4 as it allows me to write my configurations in a more modular and maintainable manner. Please drop me a line if you need assistance in this area of the project.
4 years and still using the "we have jobs" excuse?
@contra, if we somehow set up a Patreon account so the team can be monetarily compensated for their efforts on Gulp, would that help matters?
@michaelkornblum For me it isn't really about that - I started a company and I have to do right by the people who work for me by devoting 100% of my time to making sure it stays in business (https://stae.co). I don't take that responsibility lightly. In the future (hopefully if things go well for the company) I'll have time to return to OSS - I've really only been able to do the bare minimum (bug fixes, security fixes) on my projects for the past year.
99.9% of the work for v4 has been done by @phated who has generously given his time (not compensated) to work on the release. We did start an OpenCollective (https://opencollective.com/gulpjs) to help fund @phated working on the project.
There isn't anything in v4 that is super super critical to be released urgently. It's a nicer task system, and we made some other APIs better. As a whole (excluding the fantastic new task system), the API surface barely changed - it is almost entirely under the hood work. I understand people always want to be using the latest and greatest, but there is really no reason to be constantly asking when v4 is coming out when it isn't a monumental paradigm shift from v3 and v3 works great as-is.
As an aside, I strongly believe in tightly scoped projects that have a goal to be feature complete - I don't think we should release huge API changes every 3 months like other projects do.
Most helpful comment
Also, the 3.x branch works fine - thousands of companies and hundreds of thousands of people still use it every day. 4.x isn't an emergency that needs to be solved ASAP - it's minor improvements, baking in some things you can already do into core.
After the 4.0 release the project probably won't need any more major breaking releases. Sometimes projects are just feature complete and don't need to be rewritten every 3 months according to the latest trends. I'm not sure why it bugs people so much that we don't thrash our API every couple of months, and that we promote stability over complexity. It's a task runner, with some opinions about how file transformation works (vinyl) - not building a rocket ship here.