No more release schedules.

[Aaron J. Seigo]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20110614/009dfd54/attachment.sig