2.0 roadmap
vlad-zhukov opened this issue · 26 comments
Hello! I'm interested to release a v2.0 as soon as possible and I've got an approval from other maintainers to work on it on our gitter! (Join it if you haven't yet!)
This is going to be a breaking, webpack-4-only release, that updates the block API and drops deprecated ones. We also aim to make lots internal changes to make further maintaining much easier and beginner friendlier!
All new changes should go into the release-2.0 branch (#266), while master stays the same and represents the current stable release (v1.0).
TODO
- Migrate to
webpack 4(tracking issue #255). - Consider updating to
babel@7. - Remove the deprecated
fileTypeAPI (PR #260). - Remove the deprecated
resolveAliasesblock. (PR #267) - Use
yarnworkspaces (PR #268). - Decide to either upgrade
lernaor use something else (see discussion in #236). - Remove
avafrom devDeps of every package and hoist it to the root. (PR #276). - Use
prettier(PR#263#275). - Consider adding some
eslintcode rules (not style ones). - Other minor changes left in 2.0.0 Milestone.
- Cut a branch
1.0.0frommasterbefore mergingrelease-2.0. - List contributors!
Removed from 2.0 release scope
Consider updating to babel@7.
@vlad-zhukov See #257
@dmitmel I really want this to happen because I use babel 7 myself since alphas. But they keep making breaking changes in betas and suggest to pin exact versions themselves, which is fine for an app but absolutely not fine for a library. Once they announce there are not going to be breaking changes anymore (probably in rcs), we can update the block. But for now it's going to wait for some time.
I've created a release-2.0 branch, all new changed should target it instead of the master.
@vlad-zhukov babel-core is a peer dependency so our users can decide what version of Babel they want to use.
@dmitmel but Babel 7 requires @babel/core instead. Anyway, can we leave the babel upgrade for a while now please for the reason I pointed above? It's not difficult to upgrade the block itself (simply bump babel-loader to v8 and use @babel/core instead of babel-core as a peer dependency), but it's not ready to be upgraded yet and we have more important stuff to do.
I would like to focus on internal changes first, such as cut build sizes as much as possible (15min CI builds are terrible) and use of prettier. This will make our life easier and we will be able to make block upgrades faster.
@vlad-zhukov OK, we can upgrade to Babel 7 after v2.0
One suggestion I would make would be paring this list down to just breaking changes. Some of it is fluff that is not required for V2 and can be slated as followups. And getting on Webpack 4 is imo the end goal. The following list is what I think are the necessary todos for a V2 beta:
Migrate to webpack 4 (tracking issue #255).
Updating to babel@7.
Update the block API (see discussion in #125, PR #259).
Remove the deprecated fileType API (PR #260).
Remove the deprecated resolveAliases block. (PR #267)
Use yarn workspaces (PR #268) (this was merged today)
Cut a branch 1.0.0 from master before merging release-2.0 (this is already done I think?)
Write a migration guide.
Inform 3rd-party block maintainers!
Fair enough. Consider moving unpopular blocks to the webpack-blocks org or Add TypeScript definitions, for instance, are non-breaking. They could be done before or after v2 if need be.
If I know remove the whole ./packages/elm folder, we might get some rebase problems, as other commits - like yarn workspaces - touches it.
@vlad-zhukov would you be okay with rebasing the release-2.0 branch. or shall I file the PR against v2? If the latter, we need to keep in mind to sync changes between the standalone- and the monorepo 😒
@zcei Nice job! File a PR against v2 please, the master branch is not going to have any major changes.
Could you also move a test from packages/webpack/__e2e-fixtures__/elm?
the master branch is not going to have any major changes.
"Major" as in "no semver major" or in "no substantial changes"? As @andywer mentioned, it's technically not breaking for the packages. But I'm happy to open it against v2.
Damn, I was remembering the e2e fixture when I started off, but then forgot about it again, thanks 🤦♂️
No substantial changes or even no changes at all. The plan is to release v2 ASAP.
Hey, how is the 2.0 progress going?
@andywer mind releasing another alpha version? 🙏
I am very busy with other things right now, unfortunately. And it seems like so are many of my fellow contributors.
How about publishing a 2.0 release candidate and postponing everything that's not a blocker to be done after the 2.0 release?
I fear otherwise we will never get anywhere. Let's be pragmatic :)
Any updates?
@marcofugaro Thanks for the reminder. Unfortunately I have been super busy the last days and before I didn't give it the priority it deserves, since no one seemed to be pushing for it.
@ALL Can the community please help out on this one?
-> Are there any blockers left to unblock or can we go for the 2.0 release straight away?
@andywer I don't see any reasons why we shouldn't. Webpack 4 support is not a nice-to-have feature anymore, it's a requirement.
Webpack 4 support is not a nice-to-have feature anymore, it's a requirement.
Most definitely. The question is just whether there are any items on the original 2.0 roadmap that we shouldn't carelessly skip.
Here are my thoughts:
Consider moving unpopular blocks to the webpack-blocks org (issue #269).
IMO these are not essential parts of the 2.0 release, they have only been slowing it down so far.
Write a migration guide.
Inform 3rd-party block maintainers!
We don't need to do this if we don't change the block API.
List contributors!
If this is required, I can do it on the weekends.
Thx, @dmitmel! Sounds like we can release straight away then.
Shouldn't make much difference if we do the list first and release then or the other way around. Main thing is just that we have one.
Maybe we can just link to Insights > Contributors for now. Will only recognize the commits people made, not their non-code contributions like discussions, feedback, etc. Might be ok as a first step?
It may also be worthwhile to integrate https://github.com/all-contributors/all-contributors if you're really wanting to recognize everyone, although I'm unsure of it's retroactive listing ability. It sure does make it easier to add people. You could probably just install it and then quickly add everyone from the insights as a baseline.
Just merged the 2.0 branch into master and published version 2.0.0-rc under the latest tag, so it will be the default version to be installed from now on 🚀
Version 2.0.0 is out now. Basically the same as 2.0.0-rc, but with some fixed peer dependency versions.
🚀
Anyone in the mood to draft some release notes for v2.0.0?
I'm so sorry, but I got so little time to spend on webpack-blocks right now... A community effort would be awesome 😊