I finally managed to find time to catch up on the meeting I missed in February.
I have a few thoughts on versioning/supported branches etc, that I'd like to share and get some feedback on. 1) I think we should version the master branch as last-release.99.$date or something similar, so that master doesn't continue to report (2.0.0-rc1) that it is older than the current release (2.0.3) when it is in fact newer. So maybe 2.0.99-20210303 or 2.0.99-g<githash> or something like that. 2. I think we want to balance three main things: A) Releasing often enough that new features (like dRAID, or DirectIO, or RAID-Z expansion once it is ready), do not have to wait as much as a year before the next release. B) Limit the number of branches we support, to avoid over-promising, or burning up too much developer time maintaining multiple old versions C) Provide a long-term support branch for those who want a more static version of ZFS One option is, declare 2.0 as the LTS, and our next release, as not. Maybe we declare that all even numbered versions are LTS, and odd numbered versions are shorter-lived. So we'd release 3.0 in a few months with dRAID and DirectIO, then 3.1 a few months after that, with whatever else has matured in master, and keep a semi-regular cadence, maybe 3-6 months between releases. Each 3.x release would EoL the previous 3.x release after some short period (in FreeBSD, 12.1 is EoL at the end of the 3rd month after the release of 12.2, giving people a minimum of 90 days to upgrade to continue to receive bug fixes etc) The "unsatisfying" thing about this approach is that it doesn't quite track semantic versioning, as the increment of the major release number (2.x -> 3.x -> 4.x) is mostly arbitrary, and has more to do with what we decide the next "long term support" version will be. The advantage, is as Matt requested, a user can tell just by looking at the version number: if it is even, it is LTS, if it is odd, it is not. It will likely feel odd to basically have 2.0.3, 2.0.4 etc, and never a 2.1, but for 3.x to have 3.0, 3.1, 3.2, 3.4, etc, then 4.x will only have a 4.0, and get the minor bug fixes, because it is the LTS, and new features would go into 5.x. Maybe there is a better way. One idea I had proposed for FreeBSD a few years ago, was to separate the LTS from the non-LTS releases. So we'd have OpenZFS 2.0.x as the LTS, and the next LTS would be OpenZFS 3.0.x And in the mean time, we would release say OpenZFS 2021Q2, which is the short-live branch, only getting bug fixes until the 2021Q3 release, then you are expected to upgrade. The goal being to balance the 2 competing agenda: release fairly often to avoid features living only in master for a very long time, while still providing an LTS that gets only bug fixes over a longer term, to fit the needs of distros like Ubuntu LTS. What are peoples requirements, and how can we balance what is best for the OpenZFS developers, and what makes OpenZFS practical for the users? ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/Tc7a872fd1c180940-M565bab1c177102521f2f696b Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
