On 17/10/2015 02:57, Sean McArthur wrote: > I agree that all repos should use tags, since they are the correct > system in git to represent version checkpoints. > > However, I don't think a new tag should be created if there is nothing > new from the previous tag.
Tags are cheap, I quite like the idea of making a "train-XX" tag on all our repos, even if nothing has changed. It makes it explicit that we've considered things, and there's nothing going out on that train. But I definitely *don't* want to make busywork for :jrgm to deploy a train that only changes a version number in package.json. Not sure I have a solution that would satisfy both of those desires, unfortunately... Ryan > On Fri, Oct 16, 2015, 2:52 AM Ryan Kelly <[email protected] > <mailto:[email protected]>> wrote: > > On 16/10/2015 20:23, Shane Tomlinson wrote: > > I find this lack of a unified process extremely confusing, and > more than > > likely a contributing factor to week's snafu and Ryan's confusion. It > > should be easy for us to get to a better place with a unified process > > that is used across all repos. > > > > After looking across a sample of repos, tags appear to be the most > > popular way of marking a particular train's sha. > > > > My strawman proposal - *all* backend/server repos are tagged *every* > > major train. Repos do not need to be tagged at the same time, but they > > must be tagged by time the train goes to production, even if the code > > has not changed. > > A big +1. We could go so far as to factor out the grunt tasks for > tagging a release, so that they're shared across all repositories. > > Cheers, > > Ryan > _______________________________________________ > Dev-fxacct mailing list > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/dev-fxacct > _______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
