On Mon, June 18, 2012 5:36 am, Martin Gräßlin wrote: > On Monday 18 June 2012 00:26:13 Albert Astals Cid wrote: >> My concerns: >> >> * Uncertainity on the "current release state". We have people that don't >> know the current state of the release and commit new features or new >> strings when we are frozen, and that's with just one release schedule, i >> can imagine the mess with N different release schedules > "Always summer in trunk". As long as releases are not created from the > master > branch it should be fine. On the other hand nobody should commit without a > review anyway, so just commit and push without proper communication with > the core developer group is so wrong in the first place
This may apply to large projects, but KDE contains many smaller applications which don't have large teams - they may only have one or two people - able to independently review commits. New features always carry extra risk of bugs and side effects, even if they are carefully reviewed and tested. If we did feature releases more often, it's difficult to believe that for many KDE components it wouldn't result in a less stable state on average. The current 6 months release cycle seems a sensible stabilisation period for released software. More frequent releases run the danger of upsetting users more, which is something we don't need. >> * The difficulty of coding for N releases. Since the releases an not >> aligned anymore, you have to maintain code and #ifdefs for new features >> that depend on new versions of parts X of the stack that may or might >> not be used by people compiling the application. We've have some bad >> experiences with "expected versions on the stack" so i hope you're >> understanding this is not a theoretical scenario. > Also here: proper Jenkins support. CI needs to scream at you if you commit > something which does not compile. Proper Jenkins support would be a minimum requirement before we started releasing different components at different intervals. As Albert says, this has already caused problems even when we release all of KDE SC together. However, simply ensuring that everything compiles is not all - different versions of software components can functionally break things even if they compile cleanly. This has been seen on occasion with Qt in the past, and if we extend it to releasing different parts of kdelibs or kdepimlibs at different intervals, this would exacerbate the potential risks. For application developers dealing with bug reports, this is a really difficult problem - it's already the case that a particular distro can sometimes produce a bug which doesn't occur on other distros, and which the developer using another distro can't reproduce and investigate. So from an application developer's point of view, the fewer variants the better. I'd rather see a rule that we keep to a uniform release schedule, but perhaps allow individual ad-hoc exceptions if there is a really good reason. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm