[developer] Thoughts on versioning

[allanjude]

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 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

[developer] Re: (first) March OpenZFS Leadership Meeting

[Matthew Ahrens via openzfs-developer]

Thanks to everyone who participated.

video: https://www.youtube.com/watch?v=z5JoRoBbUmA

Notes:

   -

   Vdev properties
   

   (Allan)
   -

  Allan will be posting a PR about this soon to demonstrate the state
  that the code is currently in. In terms of functionality that PR is
  expected to work only with read-only properties for the time-being.
  -

  The UI/Syntax component of this change is currently modelled after
  other existing zpool commands (e.g. zpool list, zpool iostat, etc..).
  -

  Mark Maybee will be working on the vdev_noalloc feature and could
  potentially leverage the vdev properties infrastructure for his change.
  Depending on the state of the PR he may help Allan push it through the
  finish line.
  -

   More meaningful error messages for admins using zpool import
   -

  The idea here was to propagate the debug statements produced during
  pool import to the userland in order to replace generic import
errors that
  are not particularly helpful. Could be a good hackathon project.
  -

   Cleanup and refactoring of platform independent ZVOL code (Christian)
   -

  Relevant PR: FreeBSD struct bio support for zfs_uio_t (needed by
  https://github.com/openzfs/zfs/pull/11657#issuecomment-788860549 )
  -

  Currently having problems dealing with GEOM-related code - Sean Fagan
  volunteered to help over Slack.
  -

   Pool user properties: https://github.com/openzfs/zfs/pull/11680
   -

   Next Meeting Preview:
   -

  WIll take place earlier (9am Pacific in 4 weeks)
  -

  Brian may have some information/updates in the version numbering
  scheme for OpenZFS
  -

  Matt may have information/updates for this year’s OpenZFS summit.


On Mon, Mar 1, 2021 at 8:59 AM Matthew Ahrens  wrote:

> The next OpenZFS Leadership meeting will be held tomorrow, March 2,
> 1pm-2pm Pacific time.  We don't have many topics on the agenda for
> tomorrow's meeting, so let me know if you'd like to add anything.
>
> Everyone is welcome to attend and participate, and we will try to keep the
> meeting on agenda and on time.  The meetings will be held online via Zoom,
> and recorded and posted to the website and YouTube after the meeting.
>
> For more information and details on how to attend, as well as notes and
> video from the previous meeting, please see the agenda document:
>
>
> https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit
>
> --matt
>

--
openzfs: openzfs-developer
Permalink: 
https://openzfs.topicbox.com/groups/developer/Te98adfb02c2a480d-Mb4f058ef4e4114fa55161ae9
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription