-
Notifications
You must be signed in to change notification settings - Fork 6.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prepare for v3.5 release #1776
Comments
I think #1746 should be include:) |
I think #1720 should also be part of it. |
server side render(#1236) wanted ! |
Aftabnack #1720 is included @VicBell @mydearxym unfortunately #1746 and #1236 are incompatible with one another a great deal of effort has been put into both of these PRs, as maintainers we owe it to these contributors to make a decision sooner than later simple fact is that the "js ecosystem" is evolving faster and faster... at the same time, that said, we probably need to reflect a bit on where RBP fits in this brave new world. we need to keep project dependencies up to date, so for posterity i'm inclined to upgrade react router but with the understanding going forward: this project is for creating large, high-performance enterprise-grade frontend applications with advanced/custom requirements, statically delivered by CDN. my opinion is mostly based on recent experience... i'm currently using RBP for a complex application with security requirements which make SSR less than ideal. i chose RBP for scalability, fast rebuilds with DLLs, scaffolding with i18n, sagas, code-splitting, etc. i'm keen to know how you all feel about this. please leave your comments below! would love to hear thoughts from community, maintainers and the creator (@mxstbr 🙇) if you just want to "vote" for one or the other, please thumbs up 👍 comment above... feedback from the community will help drive a decision and is much appreciated! 🙏 feel free to evangelize one way or the other, but no "+1" comments ;) edit: open PRs not currently included in milestone, but worth considering:
|
Thanks for starting this discussion - I agree with @justingreenberg's mission statement (large, high performance...CDN) completely. Personally, the biggest reason for using RBP for me among the many boilerplates that exist is that most boilerplates are designed for use with nodejs and isomorphic rendering - RBP has many great features and encourages best practices for a purely static site, which is perfect for me who uses a static site that hits a Java API server; I have no plans on moving API development to nodejs for a variety of reasons. I hadn't looked at Also, FWIW, I had mostly done server-side development in the past, with just a bit of raw React before Flux was a think, but thanks to having RBP to mimic best practices from, I was able to jump into high quality, production-level web client development very easily and learned a lot about the JS ecosystem. I imagine if I had started with |
I would vote for #1746. If my memory serves me right, last @mxstbr's decision regarding SSR was to split #1236 into multiple PR's and bring |
You make some great points @justingreenberg, I too have been asking myself where does RBP fit in this brave new world with the likes of create-react-app and next.js. I haven't contributed much of late due to a lack of free time, but I certainly get the feeling we need to decide on the future direction of this project. I do remember a discussion with Max (can't find it now, could find this one) discussing the options of creating a fork of create-react-app but applying some of the best features from RBP, for example:
The above list is what I found to be the most usefull from RBP as it fits my usecase very well, but another developer might want / need Flow or TypeScript or server-side rendering. The point I'm trying to make is that it's impossible to create a silver bullet and I believe the best we can do is decide on a minimal feature set and do it very well. If it's possible we should try and architect it in a way that allows the project to be extended so requested features that fall outside the "minimal feature set" can be easily added. That feature could then be documented or forked in another repo. Maybe this is a little out of scope for this issue, but would like to hear what others think. Should we open another issue to come up with a minimal feature set? As for version 3.5 can we add:
|
I was searching for it but couldn't find that discussion either.
Added #1746 to the milestone as it got more votes. |
I'm in the middle of starting a company and building a product, so I haven't been able to do much work on Just wanted to chime in that a) go forth and release, don't wait for me and be blocked, and b) I agree with everything @justingreenberg said. I love love love @Dattaya's plan above, it's exactly what I was planning on doing but haven't had the time to. (and won't have for another good few months) |
I would love to see FlowType in RBP. I think it would highly increase robustness of the applications. Is there any plan for this? I would love to join and help. |
@Jonathan-Steinmann, it was done in #1787 |
We are looking at using this boilerplate, but are interested in react router 4. When do you guys think this v3.5 will be released? |
I'm also interested in moving this milestone along; if there is anyway I can be of assistance in getting some of the 29 PRs dating back to Dec '16, Jan, Feb etc. rolled up I would love to help out 😃 . I am slightly concerned the last offical release was ~7 months ago. I get you are busy with real life/work too @mxstbr so sorry for the nagging. Thanks. |
It's great to have you on board 😄 |
@gihrig @KarandikarMihir I found the |
I would suggest that each Pull request which will be merged in 3.5 should accompany a migration path, so when we move from 3.4 to 3.5 we can compile them easily into a readme. It would be easier to add migration plan for each pull request than to add it later. Some pull request can be ignored like bug fixes, etc. Do let me know what you guys think. I'd be happy to help in this direction. |
Hello, guys. When do you plan the next release? |
@react-boilerplate/core i just merged #1746 (RR v4, react-loadable, asyncInjector refactor)... this is the largest core change since we implemented i18n. huge props to @anuraaga and @Dattaya for their hard work on landing this. this was really the last serious update on roadmap... was there anything we wanted to include? feedback on changes introduced in #1746 would be much appreciated 🙏 |
@justingreenberg I think webpack 3 also needs to be a part of RBP 3.5.. Not sure if everyone's onboard with it.. |
I think RBP is now lost. Forgive me to say that. ^^ |
#1849 is also worth adding! :) |
All request has done, it is ready to release 3.5 ? ^^ |
@KarandikarMihir merged #1832 @react-boilerplate/core let's ship!! |
YESS, FINALLY! DO IT!!! 🎉 |
will 3.5 be a breaking change? if so, is there a migration path or steps to take (and documented)? |
@Jonathan-Steinmann Yes. It will be a breaking change. I don't think there will be a migration plan. But we'll chalk up a change log or a list of PRs that were successfully merged. |
I have tested the 3.5 and it work great thanks everyone! I have created #1921 , I think it should be considered for 3.5 as a completion of RR4 change. Edit: CI says apparently unit test fails, I'll see how to correct this if you approve the change. |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
i created a milestone to aggregate outstanding PRs we want to include in next release... i think we're a little overdue :) please let me know what you guys think
cc @react-boilerplate/core
edit: raw link - https://github.com/react-boilerplate/react-boilerplate/milestone/4
The text was updated successfully, but these errors were encountered: