add fiscal year versioning #1896
Conversation
damonmcc
force-pushed
the
dm-fy-versions
branch
from
555a971 to
f59667b
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files
☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
damonmcc
force-pushed
the
dm-fy-versions
branch
2 times, most recently
from
b5b096a to
9bdb753
Compare
| [ | ||
| "FY2020", | ||
| versions.Date( | ||
| date=date(2020, 1, 1), |
There was a problem hiding this comment.
Is this a calendar year?
There was a problem hiding this comment.
yup all the DateVersionFormat formats are declared this way. like 31 is what makes this a fiscal_year version
Since the actual start of the city's fiscal year doesn't factor into how we version our data products, I went with January 1st (no extra logic for) for now
There was a problem hiding this comment.
oh, sorry, I spaced a little bit. (read too fast, and thought this was a date default, rather than a test case). All good.
| match self.format: | ||
| case DateVersionFormat.fiscal_year: | ||
| if self.patch == 0: | ||
| return f"FY{self.date.strftime('%Y')}" |
There was a problem hiding this comment.
can you remind me what the label is used for?
There was a problem hiding this comment.
looks like it's used in
connectors/edm/publishing.pywhen promoting a build to a draftlifecycle/builds/plan.pyto resolve previous and current versions when planning a build
damonmcc
force-pushed
the
dm-fy-versions
branch
from
9bdb753 to
43ab7e4
Compare
damonmcc
force-pushed
the
dm-fy-versions
branch
from
43ab7e4 to
3ef5f52
Compare
related to #1895
CBBR publish runs were failing because versions like FY2026 aren't supported/parseable
successful publish run here
I added the printing of test coverage details to (in the future) help something like copilot suggest tests to cover changes. Might be better to do that all locally and feed it something like an XML file but this seemed harmless enough to add first.