I would strongly recommend we adopt semantic versioning <https://semver.org/> for Android Components. The spec enables clear signaling via version numbers whether this is a bugfix release, whether it contains new functionality, and whether the API is backwards compatible. It also handles pre-release and initial development semantics.
This will help keep us out of "dependency hell". -chris On Tue, Oct 2, 2018 at 2:23 PM Susheel Daswani <[email protected]> wrote: > 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 <[email protected]> wrote: > >> >> >> On Tue, Oct 2, 2018 at 1:39 PM Susheel Daswani <[email protected]> >> 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 > > -- > You received this message because you are subscribed to the Google Groups > "Lockbox Dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.com/d/msgid/lockbox-dev/CAFy2Ppd2mO5LkGhEzgGDdJOYJYzp3-4JM1xNUcegH%2Bt4jnP1kQ%40mail.gmail.com > <https://groups.google.com/a/mozilla.com/d/msgid/lockbox-dev/CAFy2Ppd2mO5LkGhEzgGDdJOYJYzp3-4JM1xNUcegH%2Bt4jnP1kQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . >
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
