Release version 1.0?

[djensen47]

I think the code quality for each release has been great, fantastic. Each release has been usable and yet better than the previous. The quality has been so good that I sincerely believe the team missed calling this library 1.0 at some point in 2017 and definitely in 2018.

Not having a 1.0 has been frustrating from at least two perspectives:

1. Breaking changes every 2-4 weeks.
2. Very difficult for 3rd party libraries integrators to keep up.

I'm actually still on 0.28 for these reasons … so that's been my 1.0. In a few months I'll upgrade to 0.30 and I expect that to take 1-2 weeks. 0.44 isn't even on my horizon at this point. This is both a good thing (really good quality) and a bad thing (I can never really catch up).

Before the Typescript refactor starts, I highly suggest that the team consider picking an upcoming, or even a past, release and just call it 1.0 or even 2.0 and while you spend 1-6 months with a possibly risky refactor, we can all breathe and catch up on your amazing progress and work from the past several months and years.

I realize that there are internal and external factors that guide the decision making and resources are finite (even if you are Google 😉 ) so thank you for at least taking the time to read my plea for a version 1.0

Keep up the great work and whatever you decide … will be the decision.

[djensen47]

After reading the Roadmap, again, maybe 0.44 should be the 1.0-beta and 0.45 is the beginning of the 2.0 work? Just a thought.

[kfranqueiro]

Thanks for the input, Dave.

This topic has definitely come up once or twice within our team as well. Indeed the primary reason we haven't tagged a 1.0 is because of the first point you mention above - the fact that we still have releases with breaking changes once per month. While we could easily tag a 1.0 at any point, given the current trend, it would simply mean that 2.0 would be the following month, 3.0 the month after that, etc., with rare exceptions. (This is already pretty much the case for e.g. MDC iOS.)

The TypeScript refactor is already underway and will most likely released in April (March would be a bit of a longshot), and we're aiming for as few breaking changes as possible (so far, anything that has required a breaking change has also been mirrored into master so that it makes it into the changelog individually and gives people a month to prepare). The one likely major breaking change is that we might be inclined to drop a few packages that have already been deprecated for quite a while.

I don't foresee the TypeScript refactor causing too much of a gap in feature development (we want to get back to components in Q2), and the goal is to make upgrading to the first TypeScript release about the same as any other upgrade, at least in terms of those who are already consuming ES6 or ES5/UMD.

PS: To your second point, I should give a huge shout-out to our third-party library maintainers who have been tirelessly keeping up with our releases, especially @jamesmfriedman with RMWC and @trimox with angular-mdc-web.

[djensen47]

Thanks for the response!

It looks like this repo is already using a git-flow like process. What about fully adopting git flow? Use a develop branch for upcoming releases and set master to be the current release. Or the other way around works too, have a release(d) branch and master has upcoming changes. Then you can release as often as you like or even on a schedule like every n months (n > 1).

Anyway, just another thought.

[kfranqueiro]

We talked with one of our teammates on MDC iOS, which uses a slightly tailored version of Git Flow. I think the main takeaway from them was that they do away with master and default to develop so that it's clear when you get to github that you're looking at the latest development and not an actual release. We could consider doing that, at least. (We once contemplated defaulting to a branch pointing to the latest release, but the downside is that the default branch on GitHub also affects the default branch for pull requests - and if you forget to set the branch correctly when first sending the pull request, the CLA bot is going to get very confused.)

Aside from that, our current release process already allows us to release as necessary. We choose to follow a 1-breaking-change-release-per-month cycle both to match Material's overarching release cycles and to give users some amount of predictable rhythm. Then we typically have one interim patch release, which we use a script to cherry-pick fixes from master against the last minor release.

Is there anything in particular you were thinking we'd gain from Git Flow?

Meanwhile, on the topic of 1.0, I floated the idea with the team of tagging the first version containing the TypeScript conversions as 1.0. The fact remains, though, that we would then most likely be tagging a new major version monthly, given the likelihood of breaking changes due to new or redesigned features. Frequent breaking changes are currently a pain point across platforms for MDC and are something that will require a lot more planning to solve.

[jamesmfriedman]

@kfranqueiro, any chance of building in a way to deprecate things? I've been doing this for a while now and it makes transitions a lot less painful. The downside of course is you sacrifice some code cleanliness and get a bit of bloat.

This might not be feasible at all given that this library is the raw bits, but wanted to bring it up as an option.

[kfranqueiro]

This also came up in our discussion with iOS yesterday. Deprecating things in JS may be feasible, but it gets hairy if it involves the HTML and SCSS, since as you said, we're documenting the raw HTML. It might be possible in some cases with some CSS bloat.

[acdvorak]

We're planning to do a 1.0 pre-release after TypeScript is merged into master (#4225) 😀

Keep in mind that this will not affect our release cadence, as we still intend to release breaking changes once per month. For example, MDC iOS is at major version 78.0.0 for this reason.

[acdvorak]

Pre-release version 1.0.0-0 has been published on npm 🎉

[alphabt]

I'm still seeing 0.44.1 as the latest on yarn. Is this just due to lag and we need to wait for some sort of publish propagation?

FWIW 1.0.0-1 is tagged as next

[kfranqueiro]

Yes, that's intentional. We usually tag releses on every other Monday, so barring any last-minute issue reports by anyone testing the pre-release, we'll release 1.0.0 later today.

[kfranqueiro]

Further update: we're planning to do another pre-release with a fix for UMD bundle typings this afternoon. We'll look to release Tuesday or Wednesday barring further issues.

[kfranqueiro]

We released 1.0.0 yesterday! We also have additional documentation updates merged and/or coming soon.

[djensen47]

Woohoo!! 🎉

[alphabt]

@kfranqueiro congrats! This project has been pumping out quality code and features. Please keep up the good work guys!