On Monday, June 18, 2012 00:26:13 Albert Astals Cid wrote: > * 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?
Especially on the last issue, I think it's important that we create a proper platform definition and communicate that upfront. That definition would include dependencies (package + version) of our own Frameworks that are required, and of their dependencies, including for example X, Mesa, QtJSon, libmysqlclient, etc. I suppose most of this information can be extracted from CMake, even. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
