Thanks for the feedback Susheel, No question about pinning, as far as i know all our products pin dependencies. It is a good practice that we recommend.
We are having a discussion in the team about dot releases. I think this is the missing piece so we will come back with a good solution for this. We are going focus on the _ability_ to do dot releases. The goal is to make this as simple as possible like 'just land a patch and add a git tag and a release will be published X minutes later'. Are the snapshots and rc releases useful? Would you actually use the RC releases? I thought that could be a good way to pick those urgent fixes. But it sounds like you want to avoid to have to upgrade to the latest version in those cases? S. On Mon, Oct 1, 2018 at 11:28 PM Susheel Daswani <sdasw...@mozilla.com> wrote: > Stefan, can we consider another improvement, based on my preference that > our Android Products *should pin dependencies as much as possible*. > > Why do I recommend pinning? This > <http://blog.chrisgorgolewski.org/2017/12/to-pin-or-not-to-pin-dependencies.html> > and this > <https://before-you-ship.18f.gov/infrastructure/pinning-dependencies/> > are compact write ups on when to pin vs. not to pin dependencies. The short > of it: Android Products ship directly to consumers, so we should stress > repeatability over reusability. When we code freeze, we should be freezing > the software (i.e., freeze our software and our dependencies), which allows > for more deterministic results. > > So if you buy that we should pin dependencies, is there an improved > release process where released builds can be* easily patched and quickly > dot released*? This would service the non uncommon and important case of > 'we shipped a version of a product that needs to be patched and released > within 2 days'? > > Thanks! > > On Mon, Oct 1, 2018 at 12:55 PM Stefan Arentz <sare...@mozilla.com> wrote: > >> Hello Android teams, >> >> We, the Android Components Team, are looking at improving our release >> process to better accommodate our product teams. This is a Q4 goal for us, >> and I am sending this now to seek early feedback. >> >> >> *Current Situation* >> >> First, how are we currently shipping our components? We have been doing >> official releases once a week, after our sprint planning. When we do a >> release, we publish the build artifacts to the Mozilla Maven repository and >> also generate the blog and documentation. Sometimes we also follow up later >> in the next week with a minor update to include an additional patch or fix. >> That patch release is more exception than rule and has only happened a few >> times. >> >> It has become clear that one release a week is not enough. When changes >> land on Android-Components, our users want to try them out sooner than >> later. And sometimes even ship them sooner than later in case of an urgent >> change. >> >> We have two ideas to work towards an improved situation. >> >> >> >> *Improvement #1 - Snapshot Builds* >> >> We plan to introduce 'snapshot' builds. A snapshot is a release that >> automatically follows master. So as soon as a patch lands in >> android-components, a snapshot release will be generated and pushed to the >> Mozilla Maven repository. As an app builder, instead of pulling in a >> specific version of a component, you would pull in a the SNAPSHOT version >> instead. This means that every time you upgrade your dependencies, you will >> get the most recent copy. >> >> (Our master branch is considered stable. So what you get is incremental >> stable updates - all our tests will be green for changes that land on >> master.) >> >> This should make it easier to stay up to date and pull in changes to the >> components for which you would otherwise have to wait until the official >> release. It allows for quicker testing and a shorter feedback loop. >> >> Do understand that these snapshots are not official releases and should >> not be treated as such. You should probably not ship with them since it is >> not clear specific version of the snapshot you get when your app gets build. >> >> >> *Improvement #2 - Release Candidate Builds* >> >> We have also talked about doing Release Candidate Builds. These would >> happen at fixed intervals in between our releases. For example, if we are >> currently in our 0.26 sprint, we could for ship one every other day: >> 0.26-rc1, 0.26-rc2 and 0.26-rc3. And then after that we ship the final 0.26 >> release. >> >> These are very similar to snapshot builds, except that you can pin your >> application to one specific build. And if you really really (really) need >> to, you could even ship with an RC build if you absolutely do not have the >> time to wait for the final release. (Again, master is considered stable). >> >> These RC builds would be automatically done on a fixed schedule. These >> builds would most likely just be Maven artifacts. No blog post, possibly no >> generated documentation. >> >> (We realize that RC is a bit misleading because new functionality could >> be added between builds, which is normally not the case for a release >> candidate - suggestions for better a name welcome.) >> >> >> One exception to the above, relevant to Lockbox, is the >> service/sync-logins component: although we do publish that component >> through our repository for consistency, it is not actually part of our >> build system. This means that changes in sync-logins will not automatically >> be picked up by our builds and will need some manual work to be included in >> a components build. >> >> >> Please let us know what you think of this proposal. All feedback to help >> us get to a final 'design' is greatly appreciated, >> >> S. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Android Product Team (APT)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to android-product-team+unsubscr...@mozilla.com. >> To post to this group, send email to android-product-t...@mozilla.com. >> To view this discussion on the web visit >> https://groups.google.com/a/mozilla.com/d/msgid/android-product-team/CAKyLfD5YUe_c0x_%3DwwcD33-Q%3DUxVnoMLsLRV3iKvn4C-Pq4hkA%40mail.gmail.com >> <https://groups.google.com/a/mozilla.com/d/msgid/android-product-team/CAKyLfD5YUe_c0x_%3DwwcD33-Q%3DUxVnoMLsLRV3iKvn4C-Pq4hkA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > 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
