>What are peoples requirements, and how can we balance what is best for the
OpenZFS developers, and what makes OpenZFS practical for the users?
I am a ZoL user since 0.6. I always got/wanted the latest official release as
soon as someone managed to package a deb or rpm, even if they were random
people on internet providing ubuntu ppa archives.
I’d always get whatever prepackaged version is available. I trust that OpenZFS
does sufficient QA before tagging a release with carefully cherrypicking what
goes into release and what not, so I presume it’s always safe to go directly in
production with official release rather than waiting months or years until the
linux distribution catches up.
>
> On Mar 4, 2021 at 5:35 AM, <Allanjude (mailto:[email protected])> wrote:
>
>
>
> 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 (https://openzfs.topicbox.com/latest) / openzfs-developer / see
> discussions (https://openzfs.topicbox.com/groups/developer) + participants
> (https://openzfs.topicbox.com/groups/developer/members) + delivery options
> (https://openzfs.topicbox.com/groups/developer/subscription) Permalink
> (https://openzfs.topicbox.com/groups/developer/Tc7a872fd1c180940-M565bab1c177102521f2f696b)
>
>
------------------------------------------
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/Tc7a872fd1c180940-M56b79b4e53e2023088392ba8
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
