Material-design-lite: 1.x roadmap after 2.0 release

[dgrubelic]

Hey guys...

Is there any docs on v2 roadmap, but to be in one place? Currently it is very hard to keep track how the v2 release will look like since everything is placed inside separate issues in some comment.. As far as i understood, you plan to break a lot of things in the v2 release, but that is not so nice to hear for us developing apps using MDL components. Therefore, it is very important to prepare our apps so it is very easy to upgrade to V2 once it is released.

One more thing that i find important in this situation is support for v1 release after v2. Do you plan to stop supporting it completely (even bug fixes)? My concern is that we will be forced to upgrade to v2 since there are still some components missing (select menus, autocomplete, chips, etc.) in v1, and mantra is not to develop them due to v2 breaking changes. Personally, i broke that "rule" few days ago by submitting date picker PR, but hey, i really need that component so i couldn't wait until v2 release.

If these kind of information exist already, i apologise in advance. :)

[surma]

Our current plans are a little in flux, but I think you are right that it would be good to have some publicly available information once we have a more concrete plan. Maybe a wiki page? @sgomes WDYT?

Re support for v1: v1 probably won’t get any further development, but definitely fixes for breaking bugs. You won’t be forces to update, per se, but it would definitely time well spent :)

[sgomes]

No hard plans here, but we're very resource constrained, and our release process is still quite time-consuming.

Realistically, we'll likely not have any other releases on the 1.0.x branch (since 1.1.x is backwards-compatible anyway), and we'll be bugfix-only on 1.1.x (as expected from SemVer). I don't expect us to have a 1.2 release unless circumstances change significantly.

Don't get me wrong, it would be great to have a 1.2 with date picker and potentially another component, but historically speaking we've needed several point releases to get new components right, with some amount of follow-up work. It seems like too big a commitment when we're simultaneously trying to replace a lot of our infrastructure and making major changes to our component model in v2 :-/

[sgomes]

Also, as for new components, @dgrubelic, it's not necessarily that we won't accept them or anything; it's just we're not focusing on them at the moment, since we're busy rewriting the plumbing :)

If like with your date picker we get some good PRs for new components, I personally am more than happy to accept them, review them, and integrate them, applying all the 2.0 changes as needed. There's already a number of existing components to modify, so an extra one or two won't really slow us down too much :)

[dgrubelic]

Thank you both for your replies.

Actually, this is something i didn't want to hear, but hey, you guys are shaping the roadmap. As i already said, this is generally because i started working on a web app using MDL and i need few more components other than date picker. Personally, i had a plan to largely contribute to the project by doing all those required components. And there is a high probability that i will.
I think that i'm not the only one in this state, there are a lot of developers wanting the same components.

This is practically a dead-end situation because we (developers) need those components, and there is a high probability they wont be included into the official v1 release...and v2 is still in it's research phase. Don't get me wrong and no hard feelings, but i think that v1 is unfinished since a developer can't fully produce app using only MDL and that v2 came a little bit too early into the development roadmap. There is a ton of stuff to fix and improve on architectural point of view in the v1 release, but that could wait until MDL covered all Material Design spec defined components. Just my $0.02 :)

As i said, other components will be developed in my personal branch, PR's will be created, and we'll see what happens. Also, i'm more than happy to help rewrite date picker or any other component to v2 arch as soon as it is done in specs. :)

Again, don't get me wrong and no hard feelings, this is just to see how a developer feels knowing MDL roadmap decisions and developing apps at the same time.

[sgomes]

@dgrubelic I totally see where you're coming from, trust me :-/ I agree that, ideally, breaking changes and exploratory work should happen at the same time that "stable" gets expanded with needed features.

It sounds like you're willing to put a lot of support behind the components you're writing, and we'd hate to see your work sit around for months with no-one using it while we're preparing a major version. So in light of all this, we could reconsider our decision (as @surma mentioned, our plans are very much in flux).

Would you be open to a quick video call? At the very least, I'd love to hear your thoughts on developing with MDL and developing _for_ MDL!

[dgrubelic]

Thanks for understanding the situation.

I'm currently unable to talk but tonight is ok with me. We can continue with this conversation in some other channels.

[sgomes]

Just to update this thread, we've decided to change our 1.x support plans:

• We will have minor releases (1.2, 1.3, etc.) for any new components that we get contributions for (such as the date picker).
  
  
  
  • The minor releases will happen while we're simultaneously working on 2.0 in master.
  
  
  • Minor releases will of course have point releases (1.2.1, 1.2.2, etc.) for bugfixes.
  
  
  • Since minor releases are backwards-compatible, we won't be doing bugfixes for previous lines. E.g., once 1.2 releases, we won't be doing any more bugfixes on the 1.1 line.
  
  
• Once 2.0 is released, 1.x will become bugfix-only.

This way we can simultaneously work on 2.0 while making new components that the community contributes available as soon as possible, as part of the 1.x line.

[dgrubelic]

Excellent! Thank you guys.

I'll do me best to submit as many component PR's as possible until 2.0 release. :)

[sgomes]

Thanks, @dgrubelic, sounds great! :)

[vmateixeira]

Great outcome!

[ghost]

where can I find more information about v2.0 ?

[lutangar]

@emd2009 for what's it's worth, I found what may be the direction of the v2.0, on the v2-components-poc branch of @sgomes, particularly in the first commit's message.
Again, as the branch's name said, that's just a proof of concept, take this with extreme caution...

[...]
Main changes:

• Moved component code to ES2015.
    Using classes, getters/setters, string interpolation and fat arrow
    syntax where appropriate.
• Removed dependency on componentHandler.
    Components are self-sufficient, with basic automatic initialisation
    on load.
• Components do not modify their own DOM structure.
    Adding and removing classes and changing properties is OK, creating
    and removing DOM elements is not.
• Removed IIFEs around component JS, as well as uniffe and deps.
    Individual components don't need to be inside IIFEs. These should
    be applied through our pipeline.
• Removed manual exporting of symbols.
    Relying on globals is not the best of practices, and this made for
    very awkward-looking code. We now use the @export syntax to let
    Closure compiler know that it should export a symbol, together
    with a utility script ('utils/export.js') that performs the actual
    exporting without relying on a hardcoded 'window' global.

[ranjit-redekar]

When you are going to release date time picker.?