Open phlax opened 7 months ago
~i think im more inclined towards non-date versions~
would be good to get some community feedback on this
once we have decided a way forward i think we need to blast it out on all channels to avoid some of the issues that other projects have faced when changing version schemas
cc @ggreenway @mattklein123
I always get annoyed because I have no idea when 1.28 was released; the timeframe gives me more of a sense of what was in the release.
If we do date-based versions, I think leaving off the day, so that it is
I think we could document that the major version of eg 202404
means that the initial release on this stable branch was in april 2024. The initial release would be 202404.0
, subsequent bugfixes are 202404.1
, 202404.2
, etc.
yeah - agree - month-based mitigates some of my concerns
+1 for month based date versions.
updated the ticket title/description to reflect this - im pretty won over to month-based tbh
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.
There have been various discussions historically about rethinking our versioning
Essentially - as we are unlikely to ever create a 2.x.x version - the preceding "1." is superfluous
The 2 proposals that have been considered:
personally, im not opposed to date-based versions (as long as they are semantic)
a concern is that version is not strictly associated to the date - so patch releases in this schema would be 202404.x, but might be actually released a year later
if we make any change to this it will require quite a bit of work to update/fix release tooling - not a huge amount, but significant
i think the main advantage of date-based versions is that they carry more information, with possible downside of being misleading for later patches