On Sat, Oct 07, 2017 at 10:17:31PM -0400, Nico Kadel-Garcia wrote: > On Fri, Oct 6, 2017 at 11:04 AM, Zbigniew Jędrzejewski-Szmek > <zbyszek@xxxxxxxxx> wrote: > > Hi, > > > > systemd 235 was released today. A large number of issues was closed > > upstream, including many bug fixes, documentation updates, and > > long-standing RFEs. There are some new features, but relatively few > > entirely new features or changes in behaviour that impact other > > services. There also are no (intentional) breaking changes. > > Systemd doesn't "intend" to break working software. But it has > repeatedly demanded, without advance notice, that working software be > rewritten to support a new and unexpected violation of working > standards by systemd. The symlink replacment of /etc/resolv.conf was > one. The killing of logged out user processes, without record and with > no option to disable it after compilation in release 230 was another > one. Do not get me *started* on the "systemd knows better than you do > or than syslinux how many active connections MySQL should support, > we'll just reset that behind your back" that I encountered recently. We'll try to do better in the future ;) You also have to admit that recently systemd has mostly stayed off the alpha/beta/final blocker lists and there's less big bugs than it the past. This is in a large part caused by maturing of the project, but also by increased automated testing and a better development process. > Systemd version updates need regression testing and burn-in. I'd like > to very strongly discourage activating it this late in the Fedora 17 > release process. > Are there any particular features you consider a "must-have" for > Fedora 27? Is there anything that justifies the risk of a late update? It's always a trade-off. I generally keep the systemd version that is in beta for the lifetime of the release (only backporting patches), but in this case we have a large number of fixes which are too many to backport (we closed maybe 70 tickets), and a relatively small number of risky changes. While keeping the older version is always safe, it also means more bugs and annoyances for the F27 lifetime. So all you say is true, in general, but in this case the balance seems to fall on the side of upgrading to 235 in F27. That's why I'm interested in specific problems that people discover or already know about. I'll be unhappy to hear them, of course, but if there are non-trivial regressions, that'll be a good reason to not do the update. > > The update is building for rawhide. If nothing major pops up, I'd like > > to release the update for F27 too. (The updates policy says that > > "major version updates should be avoided", but systemd does not use > > semantic versioning, so there's no distinction between major and minor > > releases. A number of patches was backported previously, and are > > already present in F27, but there are other fixes that are too > > numerous to backport, and which would be desirable to have in F27.) > > > > Zbyszek > > Systemd's unwillingness to use major/minor revision numbering is just > another of the reasons I don't have high confidence in the safety of > its updates. If the updates and feature additions are too numerous to > describe, then that multiplies my concern that it will break otherwise > stable software unexpectedly. I didn't like the decision to use a single version number initially, but the truth is that it'd be very hard to use "semantic versioning": the project is now stable, and each and every release is composed of a mix of new features and many bugfixes. Some bugfixes require new features to be introduced. Some bugfixes require new features to not break other use cases. Etc, etc. So depending on the specific subset of systemd functionality that you use you might consider the release minor or major. In the specific case of v235, a normal desktop user would consider the release a minor bugfix release, but (as the other part of the thread shows) some systemd-nspawn users might consider it fairly big. The NEWS file for each release contains a human-readable description of all new features and significant changes. We do our best to communicate what changed, and I don't think we would gain anything by slapping an arbitrary tuple of numbers on top. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
