On Wednesday 02 February 2011, Cyrille Berger Skott wrote: > On Wednesday 02 February 2011, Jaroslaw Staniek wrote: > > We have to plan branching rules for this, or is tagging the master our > > way (+feature branches)? Whatever works for you. > I wanted to discuss this at the sprint :)
:-). But the sprint is far away and I want something to replace the KOffice 2.3.2 release with... > My idea was to have feature branches. And trying to have feature branches > have > a as limited scope as possible, so that they can be merged quickly, but once > reasonnaly finished. Personally, I'm amazed to see how quickly this actually has started to happen, and how well it seems to work! > Some time before the actual release (between 4 to 6 > weeks), master is branched, into a "X.Y" branch, bug fixes are made in the > "X.Y" branch and merged back into master. When the "X.Y" branch is ready, it > is released (and in the mean time we publish beta/rcs based on that branch). > > And also. My idea is to four feature releases per-year. One "main" release, > with what we could call "long-term" support, released for instance in > February. For this release the community provide bug fixes release for one > year, security fixes for an other year. And then every three monthes we have > features release. The "main" or LTS release is advised for long support > distributions such as Red Hat, Ubuntu LTS, Debian or Novell Desktop. While > the > "feature" releases are advised for dynamic distributions such as Fedora, > OpenSuSE, or regular Ubuntu. > > That is a short summary of what I would suggest and use as a starting point > for further discussions. Yes, that's what I want to achieve as well -- but until we have software that's good enought I want to change from this plan: > But in any case, the current plan was to have more "classical" release until > we are user-ready. to frequent snapshot releases made from master that we can confidently label as stable, since only finished features and bug fixes land there. -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel