search

angular / material

Material design for AngularJS
https://material.angularjs.org/
MIT License
16.55k stars 3.39k forks source link

Improving the release process #1809

Closed ilanbiala closed 9 years ago

ilanbiala commented 9 years ago

@ThomasBurleson originally requested that I post this on the forum, but since the forum seems to be much less frequented than the GH issues, I figured that it's at least worth posting here so more people can see.

With each release, ngMaterial almost always includes bug fixes, which is good and bad. For example, if I set my Bower dependency to ~0.7.0, then I will only be able to use 0.7.0 and 0.7.1. Now say there is a bug fix in 0.8.0, but that has plenty of breaking changes that I don't want to include in my production app. What I'm proposing to the ngMaterial team is to have bug fixes included in patch releases (0.0.x) as much as possible, which means that I will be able to have any bugs in 0.7.0 fixed while not having to change my code because the fixes were actually in 0.8.0. This means that having a Bower dependency that uses Semver is actually good and consistent with the rest of the community. I've already proposed this, but I think the ngMaterial team is looking for enough support from the community to switch to this release process. If you support this, it means that you won't have to deal with breaking changes if you don't need to, which is what every developer hates.

kylecordes commented 9 years ago

I agree this is a good idea, but I would prefer the ng-material team divert energy in this direction after 1.0.

At the risk of sounding snarky: Material is still a relatively recent "look", but it will not be for much longer. UI design languages are, to some extent, fashions. Each has a lifetime, before it looks old and is replaced by something else. It would be really great for ng-material to reach 1.0 while Material is still the current Google design language.

ilanbiala commented 9 years ago

@kylecordes this wouldn't slow down development, it could even make it faster because bugs will be fixed before new features that depend on existing components are already created.

naomiblack commented 9 years ago

I will be the first to admit our versioning has been a little ad hoc pre-1.0, in part because we are trying to release as often as possible and sometimes bug fixes get mixed in with other things. We just had one release, for example, that was almost exclusively to fix an issue with our npm build, since npm only updates when there's a release. There is still a lot about our build and release process that's in flux. We're aiming to follow semver conventions post-1.0. Arguably, since we are still pre-release 0.y.z, we are in fact consistent with semver now. @ilanbiala you are correct that this would make things easier for developers if we were able to do so earlier, but I think this is something that you'll have to wait on 1.0 for.

ilanbiala commented 9 years ago

@naomiblack that's completely fine, but the big issue is that you guys aren't even making it easy for developers. I get that it requires a little more planning and thought, but a milestone like 0.9.0 that is supposed to fix bugs and improve without adding features shouldn't be a dot release unless you are planning on changing how things work. Even in that case, those n number of breaking changes should be separate from all the other bug fixes and refinements that people would want in 0.8.4/0.8.5/etc. so that they don't have to immediately fix their code for other features just to get 1 bug fixed.

ngMaterial is at the point where many people (7000 stars is just a small measure I'm sure) are using it in production even though it's 0.x, so you have to understand that we really don't want to have to change some parts of our code just to fix 1 bug that prevents a release from going out.