Dear Ricardo and the Cyrus IMAP community, I strongly support time-based releases.
3.2 in March 2020 sounds fantastic. JMAP in a stable release: yes! FYI, we use Cyrus IMAP as part of WikiSuite: https://wikisuite.org/Cyrus-IMAP Another component of WikiSuite is Tiki Wiki CMS Groupware. The Tiki project started in 2002, and since 2009, has been using a time-based release schedule. It is __by far__ the most important decision we ever made. A time-based release process has the benefits described by Ricardo. And more. It gives a rhythm to the project. More things get contributed. Features are sooner accessible to end users, and thus, get feedback and improvements. A related important question: what is the support lifecycle? In Tiki: A major release every 8 months, which is supported for 9 months. Every 3rd version is a Long Term Support (LTS) version, which is supported for 5 years. Here is some detailed information about the process: https://tiki.org/Versions Given upcoming versions will be quite frequent, it would be really great if (for example) 3.0.x could be chosen as an LTS version with security fixes for a number of years. Thank you and best regards, Marc On Fri, Dec 13, 2019 at 10:01 AM Ricardo Signes <r...@fastmailteam.com> wrote: > > Hey, remember last month when I asked about releasing Cyrus v3.2? > > That thread had some more conversation about what needs to get done before > v3.2, and I wanted to come back to it and turn some things on their head. > > Right now, we’re talking about Cyrus releases being feature-bound. “We’ll > release v3.2 when feature X is done.” I think we’re not being well-served by > that. As feature X is delayed (for various reasons that we can’t easily > eliminate), it doesn’t just delay the feature, but also all the other minor > bugfixes and optimizations that we’ve made in the master branch. Also, it > sets up the idea that we delay releases for the sake of fixes, instead of > releasing the fixes that are ready. > > That is: every additional criteria for a new release is another doorway to > delay. Instead of opening those doors, I would rather try to eliminate all of > them. > > I propose that instead of tying releases to milestones, we tie them to the > calendar. For the sake of full disclosure: I am modeling this suggestion on > the release cycle of perl, which I ran for several years. I found the process > more than satisfactory, then. > > A new unstable release of Cyrus is made every month. We promise only that it > compiled and passed the Cassandane test suite on the release manager’s > computer. It might contain regressions from previous unstable releases, it > might have crashers or corruptors. We try to avoid any of these, but the goal > here is a snapshot for easy month-to-month testing. These are the > odd-middle-digit releases. (3.3.x) > > A new major release of Cyrus is made every year. We will have tested it on as > many configurations as we can readily test. We will have, some time before > the release, frozen the branch for risky changes, to reduce churn. In the > meantime, new work lives in feature branches. (The changelogs from each > unstable release provide a good basis for the whole-year changelog!) These > are the even-middle-digit third-digit-zero releases. (3.4.0) > > A new maintenance release of Cyrus is made for the last two stable releases > when there are enough fixes to critical bugs to warrant it. These are the > even-middle-digit third-digit-nonzero releases (3.4.1) > > For the above to work, some more properties need to be maintained. > > Maintenance releases should be no-brainers to install, so they must only fix > regressions, crashers, security vulnerabilities, and the like. This means > that once you’re on 3.4.0, you can always upgrade within the 3.4 series with > a minimum risk. It also means you get no optimizations, features, and the > like. > > Major releases must clearly document any incompatible changes or upgrade > steps required. Because non-regression bugfixes aren’t backported, we want > everyone to be able to upgrade from major release to major release, so > incompatible changes must be kept to a minimum. > > In part, this is just “don’t kill off a feature people use just because it’s > a little annoying.” The more important one is “don’t introduce half-baked > things that might need to change,” because people will come to rely on them > before you get the updates finished. For features that will require multiple > years to get right, they have to go behind a default-off configuration > option. I’d strongly suggest they all have a uniform substring like > “unstable”. That way, when a complaint comes in that the behavior of JMAP > calendaring has changed, we can reply, “well, to use it, you had to turn on > the unstable_jmap_calendaring” option. > > If we go with this policy, we’ll need to… > > identify what issues are blockers to v3.2.0, meaning they’re regressions from > v3.0 and would reasonably prevent someone from upgrading; this does not > include all known bugs, since they may be bugs that already exist in the last > stable release! > > pick a release target for v3.2.0; I will arbitrarily suggest March 2 as “not > too far off, but far off enough that we can get things in order”; also, if > you’re American, March 2 is 3/2 ;-) > > produce a changleog, and especially identify what changes in master need > documentation as “incompatible changes” > > produce a list of changes in master that should be put behind an unstable > configuration option and then do it > > decide when to stop merging non-release-related things to master > > make a plan for who will do monthly snapshot releases > > I’ve spoken with ellie and Bron about just a few of these, such that I don’t > think it’s all crazy. (ellie notes, correctly, I think, that the first set of > releases like this will be the hard ones, where we work out things like “how > do we keep track of incompatibilities, upgrade steps, and also how do we make > snapshots dead easy to release.”) If there’s general agreement, I am > definitely ready to pitch in and help try to make it work! > > — > rjbs > > -- Marc Laporte http://WikiSuite.org http://PluginProblems.com http://Avan.Tech
