Release cycle after 6.2 Current release cycles: * One stable release every half year * A LTS with 4.5, another one with 6.2 3 years later * LTS maintenance with overlap to next LTS, so > 3 years, 4.5 will be 4 years maintened in 4/2015 * Non-LTS maintained for 1,5 years * Releases go to "priority and security patches" after a half year, or 1 year * \url{https://typo3.org/roadmap/} Problems with current cycles:k * 3 years between LTS is too long and has tons of negative side effects * Many people are bound to LTS versions only and can not upgrade to new and hot shit * CMS looks and feels "old" if only using LTS * Agencies / customers can not upgrade and test new stuff in time * High pressure in the development team before new LTS versions, suddenly everyone wants to get everything in, higher risk for regressions and half-baked stuff * Features that are in for a long time suddenly show they are not complete (cf was default with 4.6, race conditions in code fixed shortly before 6.2) * Deprecation strategy is documented, but unclear to most public and also unexpected to some (i.e. deprecated in 4.7, removed in 6.1) * Feature freeze phases are too long * Non-LTS versions are not wide spread and not heavily in use * Developers see merged core features in the wild only after next LTS release, this is frustrating * Working with 3 year old LTS for new projects is no fun for developers (try to use extbase in 4.5, or be stuck with non namespaced code) * Projects like "smooth upgrade" have to be done before next LTS to catch up with the changes done in three years * Extensions tend to not be compatible with non-LTS, do not use younger features Good things about LTS: * Looong support ^^ * Future proof of investment * Marketing New release cycle gives more freedom to everyone: * LTS ~ every 1,5 years * (Image by Ernesto to show this) * No other big releases in between * Support for LTS = 3 years each plus overlap with overnext LTS * Time between LTS releases is filled with "snapshot releases", but more often than 6 month * Snapshot releases have no patch level releases, instead it is advised to jump to next snapshot * Provide automatic upgrade scripts from snapshot to snapshot, including rollback if something went wrong * Snapshot releases aim to work as such: A couple of features is integrated within a "merge window", then feature freeze is declared followed by a stabilization phase where the features are either stablized to be production ready or thrown out again, with chances to be merged again in next merge window. If everything works, a new production ready snapshot release is done. Then the cycle begins again. * Snapshot phases should be as short as possible, maybe for example 6 to 8 weeks, but dev team is free in this regard * Version madness solved: 7 LTS, 8 LTS, 9 LTS, snapshot releases are called 7 pre, 8 pre, 9 pre, ... * Deprecation strategy is cleaned up: deprecated in "7 branch" (7 pre, 7 LTS), can be removed in "8 branch" (8 pre, 8 LTS) * Deprecation "removal" can be done once shortly after a "LTS" release in the next "pre" branch Expected effects: * At maximum, 3 releases are supported: "fresh" LTS, "in between" LTS and "old" LTS, where "in between" and "old" are both in "priority and security" bugfix mode * Agencies have the choice: If starting new project, they either choose "current" LTS and develop on in, giving customers support for the remaining life of this LTS before upgarde is needed. Or they start with a snapshot release, upgrade during development of project until next LTS comes, or they even stay on snapshots as long as they want. * Automatic upgrade pathes done during snapshot development define a clear upgrade path from LTS to LTS in the end, "smooth upgrade" projects can be obsoleted because they ared done and tested during snapshot already. * Projects bound to LTS versions only can leap over one LTS and still have full support times * With the feature driven snapshots, active contributors can concentrate on single parts of the core for one snapshot release ("topic snapshots" or "sprint topic"). * More agile process Details to be discussed: * What means automatic update / downgrade, what do we want to provide, which parts are targeted (beside DB)? * Moving files around is nice to have. The Symlink way is proven, easy to handle and the windows users are used to a longer downtime during an update. * Deprecation strategy (discussed in meeting 2014-05-05) * How it will evolve? * Suggestion: * no removal of stuff during rolling releases, just "deprecation" * final phase (6 months?) before LTS release should stop deprecation (to allow extensions and integrators to adapt before LTS comes out) * removal of deprecated stuff right after LTS release, in the next rolling release branch * start over * What about system requirements, compatibility, when do we "update" them? (discussed in meeting 2014-05-05) * What systems, system requirements * Decide on them pretty early after last LTS for next LTS * New PHP versions: update minimum PHP requirement on every major * New MySQL versions: update minimum MySQL requirement on every major * Browser Support (Internet Explorer) - not so critical, could be decided earlier in between if it makes sense (IE now also started to have shorter release cycles). * Update minimum requirements on LTS release. * Same principle as deprecation strategy * An LTS should also update maximum requirements as time passes, in order to be able to install the "latest LTS" also on a newer machine (see \url{http://forum.typo3.org/index.php/t/199084/} when we specifically rised max-requirement for 4.5 two years after release). * How to involve extension authors in this system (not discussed yet) * Good documentation (different from todays docs STUFFED with examples) and an API for the most FUF (Frequently used functions :)) * Examples of FUF * Add field to schema * Remove field from schema * Backup field of schema * transform CSV to MM * transform MM to CSV (yes, I know, but we need a way back ;-)) * What about version numbers? (discussed in meeting 2014-05-05) * Snapshot releases are 7.0.0, 7.1.0, 7.2.0, and then 7.13.0 (or whatever) is version that is nick-named LTS that gets patch level releses? * "Ze germans" would react better to something steady (think: x.50 is always the LTS, so 7.50, 8.50 etc.) But the problem might me a minor one - just needs communication. * See also Semantic Versioning: \url{http://semver.org/} * Inspired by Linux Kernel versioning * 7.0.0, 7.1.0, 7.2.0, 7.2.1 (only some bugfix), 7.3.0, ...., 7.20.0 => "early adopters" branch * 1.5 yr later: 7.20.0 => "LTS release" * 7.60.1, 7.60.2, 7.60.3, 7.60.4 => "7 LTS patchlevel releases" * Snapshot version tagged and released directly from master * Merge Window * "Stabilizing a snapshot" phase (AKA "feature freeze" phase, but shorter) * perfect scenario in the future: only stable components are merged * no stabilization phase needed * tools (to be built) take care of pre-checking those new components * What about release management? Do we need it at all? With the snapshot releases we would have the chance to switch more often, this may be beneficial to take load from RM. * Maybe switch RM to PO? The work will be much more like the one of a PO anyways. * Building up communication prior to release might the the trickier part. * Maybe we should define the tasks that need to be acomplished and then decide if we need one person, two different ones, or a team (CMS team) and which ones could be "rotated" and which ones should have a fixed person: * maybe cycle responsible PO/RM between each snapshot, i.e. use code sprints as "time frames" * decide about if a controversial feature gets in or not * decide about timing issues (merge freeze phase, snapshot release, ...) * organize issues in the tracker, prioritize todo's, do "project management" * plan and organize TODOs and the workflow in code sprints * communicate about what's going on to the public * be available for the press team and/or interviewers to write or review articles around CMS development * publish or write "release notes" * Who decides on snapshot freezes / releases? * The build server, or did I missunderstand? * Still humans / CMS team members need to decide when a new snapshot can be build, what it can include or what is not stable enough yet Next steps: * Improve this notes * Have a meeting about open points * Create a blueprint from notes document, communicate with cms team \& core list: * lolli kick starts Blueprint until 9.5.2014 * finalize blueprint until mid next week (14.5.2014), get consensus between "us" * give to core list, then have ~ a week for feedback * @todo Tom: will write about what is "needed" to get this project going (tools, ...) * Decide on further next steps * Nice marketing \& communication article with graphics and stuff * Find a nice name for the release process * Create new project on forge to collect organizational tasks COLORS: Mathias Lolli Ernesto Tom #Meeting 2014-05-05 Notes Olly, Lolli, Tom, Ernesto * Install Tool via CLI: Lolli will work on that * "Huge patch" problem with gerrit * Ideas: * "catharsis" fork on Github like Lolli * "Incubator" branch somewhere * Work on github with pull requests using "pull requests" and push to gerrit * \url{http://nvie.com/posts/a-successful-git-branching-model/} * Snapshot releases and sprints * Sprints seems to be most useful at the end of a stabilization phase * Release "some days" after sprints * Naming things * Early adopter * Not: "rolling releases" * Not: "release cycle" (too generic, does not say enough about agile \& snapshot stuff) * System Requirements * For "7.0" drop PHP 5.3 * Change System/PHP requirements only with new LTS branch (e.g. 7.0) * Browser requirements eventually can change even during the preview process ###Next meeting next tuesday together with the CMS team meeting Code Sprints 2014 * 10.06 - 12.06 - Sprint Zurich/Switzerland (at Snowflake Productions GmbH) * 24.07 - 27.07 - Sprint Stuttgart/Germany (at B:13 or at cronIT) * 08.09 - 10.09 - ACME Munich/Germany * 23.10 - 26.10 - Sprint Linz/Austria * 08.12 - 10.12 - Sprint Berlin/Germany (at CPS-IT) #Meeting 2014-06-20 (T3DD14) notes Participants: Christian Kuhn, Ernesto Baschny, Anja Leichsenring, Thomas Maroschik, Helmut Hummel, Frans Saris, Stefano Kowalke, Susanne Moog, Oliver Hader Time: 8:00pm - 9:20pm * deprecation strategy * find a way to document changes WITH the code that can be parsed and used * better not having a centralized registry since it might get outdated or forgotten very fast * combining that with the actual source code allows to keep that updated even if it gets modified or moved again * example (create a template for the detailed reST file) * @deprecated since [7.1.0] * @see [fileThatContainsDetails.rst] * see issue on Forge \url{http://forge.typo3.org/issues/59740} * feature documentation * replacement for NEWS.md fine * similar to detail file of deprecation strategy * see issue on Forge \url{http://forge.typo3.org/issues/59741} * version numbering: having a fixed version number, e.g. 7.50.0, even if the only have been 23 snapshots before * might be a requirement for extension authors to set the supported versions correctly * controversal discussions for not having gaps in the actually available versions * decision is postponed to the time when it gets closer to the final release * snapshots * naming it "EAR": need to rethink and find a better name for that * snapshots shall contain detailed information about what was changed, deprecated, removed and added on an automated way * personas/release management * better to have somebody to keep track of what is ready and what probably needs to be removed again (or does not get merged at all, yet) * cms team / release team serves as backup, if nobody is up for taking that position (which will be the case in the begining) * practical working mode with Git * having feature branches (refs/features/whatever-topic/) * having a group of interested developers for a particular topic - not only one person working on a particular feature * having the reviews done already in those feature branches * if the feature topic is ready, cherry-pick (or even merge) the single commits to the master branch and keep the history and reasoning behind each change * things to be done * modify the release script to be able to handle snapshots/EARs * create a BaseDistribution (like Flow/Neos) and have the release script updating the composer details there