El Divendres, 15 de juny de 2012, a les 13:05:44, Sebastian Kügler va escriure: > Hi all,
Hi > During our sprint in Pineda de Mar, we sat down and thought about how our > release cycles relate to the structures in our software, we came up with the > following proposal we'd like you to consider and provide feedback about. > > Starting with KDE Frameworks 5, we will release Frameworks, Workspaces and > Applications each with their own release cycles. Each of these releases > would be a set of tarballs of the latest stable versions of the application > (or codebase in more general). > As an example, Frameworks could release updates every 2 months, while our > application collection is updated monthly. New iterations of the workspaces > come every four months. (These numbers are completely arbitrary, and here > only for illustration purpose!) > > More specifically for the Workspaces, we would like to release all > workspaces at the same time. > > This model would > > * Allow components to skip releases if they need to take a longer > development cycle > * encourage developers to have an always releasable master > * put more emphasis on continuous integration and other automated testing > > As far as we can judge, this would be in line with our communication > strategy, and allow us to target different groups more clearly. That is > something to streamline with the people at kde-promo, though. > > Opinions? My concerns: * Need more people to do the tarball packaging/releasing (since if you propose to release that often you can't expect the same person to be doing packages almost weekly or byweekly given the release dates won't probably align) * 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 * 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. What's your opinion on these issues? Cheers, Albert > > Aurelien, David, Dario, Vishesh, Alex, Aleix, Martin, Martin, Marco, Björn, > Kevin, and _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
