My initial reaction to '[a]lways develop against components -SNAPSHOT so that you stay up to date' is we likely won't upgrade components versions unless there is product value and some assurances of stability when doing so (i.e., a Product Manager says I want the changes, bug fixes or features in that component update, and the component has been tested to not introduce regressions from previous versions). I would also say that just getting bug fixes is usually not enough product value to update (a point release of our pinned version is probably preferred).
I would love to hear what other APT engineers think on all this though. On Tue, Oct 2, 2018 at 11:31 AM Stefan Arentz <sare...@mozilla.com> wrote: > > > On Tue, Oct 2, 2018 at 1:39 PM Susheel Daswani <sdasw...@mozilla.com> > wrote: > >> Yes Stefan, I don't think the snapshots and rc releases are super useful >> *yet*. We do use them with GV but that's really just because GV >> development is so active and the engine is so core that updating it more >> frequently overrides the risk. But being on the bleeding edge does have >> it's issues (e.g., yesterday we had to downgrade GV because it was too >> bleeding edge). >> > > I think what we will recommend to all teams is actually this: > > - Always develop against components -SNAPSHOT so that you stay up to date. > Snapshot is the place where you will get the changes, bug fixes and > features that you have requested. And you will get them real-time as those > changes land. Using snapshots is the best way to work together with us > because not only will you get the things you need soon, you will also find > issues sooner which means we get to a stable release sooner, which means > less chance of point releases. > > - When your project reaches code freeze or feature complete, that is the > moment you stop using snapshots and pin to a stable version. In an ideal > world the timing is such that our calendars are in sync enough that you can > just pin the upcoming release. But if they are not, you can tell us the > point in time when you would like to pin components and we can make a > release happen on that date. (Note that this does not scale well beyond one > or two products, it is simpler to take our release dates into account and > align schedules.) > > The point releases are to handle unexpected (aren't they always) critical > bugs, they do not exist to accommodate a development schedule. However, > they can happen after you pinned to a specific version or even after you > shipped. But I think that with a good schedule and good testing, these > releases can mostly be avoided. > > S. > > -- Susheel Daswani Senior Mobile Engineering Manager phone / text: (415) 218-7259
_______________________________________________ Sync-dev mailing list Sync-dev@mozilla.org https://mail.mozilla.org/listinfo/sync-dev
