On Thursday, June 9, 2011 18:07:33 Tom Albers wrote: > ----- Original Message ----- > > > Weren't you the one proposing that subprojects should adopt their own > > git > > workflows? I'm quite puzzled about how problematic this would be. > > Since KDE is the community, how can we do a KDE 4.8?
as we always have: we do a coordinated SC release. > And then Platform will call itself 5 if I understood correctly. completely undecided, and almost certainly not by 4.8. 4.8 will likely be the current kdelibs + critical fixes .. we'll be working on Frameworks to make it a timely release with Qt5 and because we have limited manpower to make all that happen, but 4.x releases will continue, from master kdelibs and kde- runtime, until we are ready to make that jump. when we make that jump is yet in the future. and one easy way to do this _when we get to that point_ is probably something like: * the Frameworks branch merges into master * any further 4.x releases are made from the last stable 4.x branch in kdelibs/kde-runtime * apps can start porting as needed, either in branches or in master, something we can determine as a community when that time comes. but that time isn't going to be here until next year, so we can decide this probably post-4.8. > So how do we call a new release schedule then? good question. let's discuss this at the Desktop Summit where the bandwidth is high enough to do so productively. we have a git workflow that is a result of doing such in-person discussions, let's take this as the next logical set of answers we need. let's also keep in mind that we'll probably enact them sometime between 12-18 months from now. > Then there will be a new workflow for kdelibs, with new policies about what > to release from which branch. I just don't think one release schedule will > fit all modules. actually, with the new workflow, this is a moot point. in fact, it's designed so that this doesn't matter. if master is "always releasable" then we can simply branch x.y when feature + string freeze happens and do the releases from there instead of from master. development can continue in master as always, improvements and fixes become the responsibility of the projects just as it is now. iow, our release engineering should need to change very little and projects will only need to adjust according to their own needs (e.g. do they need an integration branch? do they wish to just follow the SC releases, and move to the stable branch immediately when it is made, only returning to master when the freeze is up? etc.) we need to document the possibilities, of course. we're not even finished documenting the git workflow itself yet, though, so one step at a time :) > Just like kdepim could not follow the release schedule the last releases, > kdebindings have troubles following it now and then, kdevelop followed it > now and then and koffice wants to follow it again, I think it's time for > more 'freedom' in this area... i agree; i'd love to talk about this more in berlin... hopefully release team people will be there? :) and thanks, btw, for caring enough about these issues to speak up on them. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
