4 ms·

Honestly I've been leaning towards: [dev || qa || prod].[BreakingChange#].date prod.4.2016.02.19 qa.5.2016.02.19 dev.5.2016.02.19 Useful semantic informati

• tracker1 11y ago
  Why is your dev/qa/prod code different? For that matter, you could use a julian date... break.year.julian if, for some reason more than one a day break.year.julian-patch##
  • fweespeech 11y ago
    It's a statement of stability. Dev is frequently the next breaking change and/or code tested solely by is creator. QA is code going through the in-house QA process and is basically a previously nightly build which is trusted enough to be tested against live data. Prod is the last QA promoted to production + any hotfixes. Library changes are slow due to the need to verify we aren't breaking production systems so we frequently have a Prod that doesn't match QA that doesn't match Dev because the process can take a month for breaking changes. Even for non-breaking changes, we generally freeze production for ~1 week if the changes are substantial enough that we might have missed something. We can't exactly ignore production bugs for 1-4 weeks. --- The problem with Julian Dates isn't they aren't immediately human readable which is useful for lining up what was running when.