add a roadmap site #353
add a roadmap site #353
Conversation
| @@ -0,0 +1,25 @@ | |||
| Roadmap | |||
There was a problem hiding this comment.
Maybe expand the text a little further and just mention some very high level goals like catching up on Java language features up to 21, catching up on emulation and removing classic DevMode?
For the concrete releases then only link to their corresponding Github milestone. That would avoid duplicating milestone information/issues and you don't have the burden to keep it in sync in case planing changes.
There was a problem hiding this comment.
You are right. Using more high level goals will keep the amount of maintaining low.
Good point.
There was a problem hiding this comment.
I don't think we have any intention of removing legacy/classic dev mode - it has long since (2.8?) been discouraged/deprecated, but I'm not aware of anything that would necessitate removing it? Certainly there are things it can't do.
There was a problem hiding this comment.
ok. I'll remove the deprecated/removing stuff.
There was a problem hiding this comment.
I was more thinking along the lines of:
"GWT's roadmap is planned on Github using Github Milestones. Milestones should cover the next two releases and because priorities can change please check milestones directly on Github for all the details.
As a high level goal next releases of GWT focus on bringing Java language features as well as JRE emulation up to Java 21. Additionally GWT explores support of some J2CL exclusive JsInterop features in GWT compiler."
That's it. No listing of releases at all.
There was a problem hiding this comment.
You are right. Sounds good. Just change 'Milestones should cover' into 'Milestones will cover' and chhanged 'next two releases' to 'next releases'.
|
@niloc132 Are ther other high level goals to mention? |
| @@ -0,0 +1,25 @@ | |||
| Roadmap | |||
There was a problem hiding this comment.
I don't think we have any intention of removing legacy/classic dev mode - it has long since (2.8?) been discouraged/deprecated, but I'm not aware of anything that would necessitate removing it? Certainly there are things it can't do.
src/main/markdown/roadmap.md
Outdated
| * Deprecating classic `DevMode` | ||
|
|
||
|
|
||
| * Catching up on Java language features up to 21 |
There was a problem hiding this comment.
gwtproject/gwt#9794 could be added.
There was a problem hiding this comment.
Using the comment from @jnehlmeier, this change is no longer relevant.
|
This is pretty light on actual details, but at least it does get the user looking in the right direction to see where this is tracked. Thoughts on a github issue label or milestone to denote "this task is looking for a contributor/sponsor"? My thinking is that we could also summarize that the milestones aren't fixed, but if someone was hoping to get another feature in to a release, that would be a good starting point? I'm not familiar with how other projects handle this (outside of "Sorry, we don't take external contributions" or "If you want to work on this, ask us first, and tell us your whole plan before starting", etc). |
Kind of depends on what the 2.x branch should become? Everything that is not related to compiler, java language features and emulation would need to be done twice: once in the 2.x branch and once in the J2CL compatible library if it exists. Otherwise the upgrade path could cause trouble if bugs re-appear and such. Usually these labels are more used to mark easy issues for new contributors. I mean every issue is looking for a contributor to solve it, so I don't see the point of marking some explicitly. But of course we could add some text to this PR to clarify that additional contributions are welcome, even if the issue is not planned in the roadmap. I get that having a roadmap will make some people happy as it implies someone is thinking about the project. But as soon as we commit this PR someone needs to actually plan releases continuously. An empty roadmap looks bad as well. So in reality I personally would favor an automated quarterly release and what's committed in main will be released (no manual smoke testing anymore). Nobody needs to plan then but obviously no concrete roadmap would exist then as well. We could define priorities / high level goals though, possibly as milestones or projects. |
|
I'll added informations about donation and contributing. |
I'll like the idea of a automated quarterly releases. Also having deployed a HEAD-SNAPSHOT version would be great. (do we have that?) I have no problems using a SNAPSHOT during development. In my experience a better way than a smoking test. But that's something we should discuss anywhere else (GWT Project Discussions?) |
There was a problem hiding this comment.
I would definitely like to flesh out more, discuss the stability and maintained status of GWT 2, and offer a plan that doesn't bring "GWT 3" out as a product, but as an ecosystem (j2cl+closure or gwt-dev to compile any code that is roughly compatible between them, call out examples of libraries, etc). Ideally that would include offering a "lighter" gwt-user (and a compiler that doesn't shade everything), something that only includes the core language details and jre emulation, for faster builds and smaller downloads. Naturally, to also meet the "stable" requirement, we have to hold on the the old artifacts too... but that's its own problem.
I'd also like specific guidance on "how to provide/sponsor a change", including our ideals of backwards/forwards compatibility, which repository to put a given change into, how to raise an idea for discussion before getting started, how to ask for help, etc.
But as above, I think this is great for today, and pushes us in the right direction of having a place to provide plans, timelines, and principles that will guide the release, so that users and contributors alike can have something to reference.
A roadmap provides confidence for customers of the GWT SDK.