----- Original Message ----- > Seriously, though, you can still publish a KDE *SC* 4.8 (or 5.0 or > whatever) > and a corresponding release schedule called exactly that.
I think it is even more confusing to release kde sc 4.8 with for example, platform 5, pim 4.7 and plasma 2. What exactly does 4.8 stand for in that case? > This is absolutely true. Creating distro packages from such a version > mix will > become a nightmare. Not to speak of the problem that there will not > be a > common "KDE SC experience" across all distros anymore but a pretty > much random > collection of modules according to the individual release plans of > both > modules and distros. (Not to speak of us source-based distros with > "rolling > releases".) I doubt the release schedule can keep that together. If the platform releases version 5, distro's need to package it and then ship 4 too and some kde modules will be compatible with platform 5 and some won't ever. So, however we turn it, I see we can add some structure, but I do think that structure needs to be set on a per module base, no longer on a central base. > Even today, some distros have either not even started working on the > 4.7 beta > because of the comparedly small mess we're already facing today. My > guess is > that those alphas (at different milestones) won't get much testing at > all > because we, as packagers, will likely have a hard time puzzling all > the pieces > together properly - and some of us most likely won't even bother to > try. Sure, and we can see a 'deadlock' in this mailinglist with that subject. Some packagers are ok with splitting, some want it consistent and some want it monolotic. I think the module maintainers should have a bigger role and responsibility here, as there can not be one guy on this list which decides all this. I'm very concerned about the 4.7 release tbh, because I don't see a solution appearing while we need one asap. Maybe if we split it up and have responsible 'leaders' for each module we can prevent such situations and have a better uniform communication. > So, if they don't like to work toward it, there won't be unified KDE > SC > releases anymore? And even if there are, there will be only *two* > releases a > year? I'd consider that a *major* step beackwards. 2 or also for all the minor release of just 12 release moments a year, that was not the point. That are details... > > > Coordinate? We *create* releases and manage them. > > We can still package and release them if you like, that's > > independent of > > the schedules. > > Uhm... No? *What* are you going to package? How are you going to make > sure > whatever you decide to package is actually going to work with the > other > modules? Of course, you can randomly pick some date, package and > release > whatever is available at that point but, from a QA point of view, > this might > not be the wisest approach to release engineering. Well, it's up to the module maintainers to work out the release schedule to reach a stable release at the release point. I think that will work fine. We won't go randomly tarball some random folder. Thanks for the mail. It helps to clarify this idea better. Best, -- Tom Albers KDE Sysadmin _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
