As mapbox-gl-js becomes more widely deployed, stability becomes more important.
Our current release processes bundles both bug fixes and new bugs features into each release. Users who don't need the new features might want to upgrade to the latest release for bug fixes, however the new release may have new features bugs too.
One solution is to backport bug fixes from each release the previous minor release. Bug fixes in v0.18.x would be backported to create new v0.17.y releases. This process could be largely automated (git cherry-pick).
Thoughts?
cc @scothis @ansis @mourner @tmcw @jfirebaugh @kkaefer @1ec5
lucaswoj
>All comments
Creating and testing releases, and then integrating them downstream, takes time, and at the speed at which mapbox-gl-js is moving, backporting could be a significant overhead. I don't think we should do this unless we get specific outside pressure and there's concrete value attached (i.e. 馃挵 ). In my opinion, our time is better spent developing new features and improving our test automation so that fewer bugs make it into a release.
FWIW, except for a couple of security patches, we've never done this for Mapbox.js, and I don't think we've ever gotten a request to do so.
jfirebaugh
on 30 Apr 2016
Related issues
rasagy
路
3Comments
bgentry
路
3Comments
aaronlidman
路
3Comments
foundryspatial-duncan
路
3Comments
aderaaij
路
3Comments
Most helpful comment
Creating and testing releases, and then integrating them downstream, takes time, and at the speed at which mapbox-gl-js is moving, backporting could be a significant overhead. I don't think we should do this unless we get specific outside pressure and there's concrete value attached (i.e. 馃挵 ). In my opinion, our time is better spent developing new features and improving our test automation so that fewer bugs make it into a release.
FWIW, except for a couple of security patches, we've never done this for Mapbox.js, and I don't think we've ever gotten a request to do so.