[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: 5.0 and 5.1 Release Plans
From: Aleix Pol <aleixpol () kde ! org>
Date: 2014-06-30 17:15:10
Message-ID: CACcA1Rr2yyqp_OBhrQp_W7p582dfYP3LZ91ZX6v5d3UdANOWsw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Jun 30, 2014 at 7:06 PM, Marco Martin <notmart@gmail.com> wrote:
> On Monday 30 June 2014, Jonathan Riddell wrote:
> > At the Hangout meeting today it was decided to go with a three month
> > release cycle and bug fix branch and to use this cycle for 5.0 and 5.1.
> >
> > I've updated the schedule http://techbase.kde.org/Schedules/Plasma_5
> >
> > RC tagging and tars this Thursday
> > 5.0 tagging next Thursday when I'll make 5.0 branches too
> > Four week later is 5.0.1 from stable branch
> > Four weeks later is 5.0.2 from stable branch
> > A week after that and is 5.1 beta and freeze for features and messages
> > Four weeks later is 5.1 release
>
> not completely sure the bugfix branches would be used that much, I guess we
> have to see how we can work with it
>
> one thing that occurred to me after the hangout this morning, is that the
> plasma-framework part that is a big part would have the one month schedule,
> while the workspace parts would be 3 months, that sounds kinda weird.
> but i guess we could say no features on every third release of plasma-
> framework, so synchs with the workspace.
>
> last thing, if the workspace has a slower cycle than all the frameworks,
> means
> that it should always work with several frameworks releases at once, since
> we
> wouldn't know what mix of version ends up in a distribution.
>
>
It's quite unfortunate the fact that we'll have a more schedule for the
frameworks and then the workspaces won't be able to take advantage of those.
I don't think it makes sense to decide to stop the development on a
plasma-framework, because after-all plasma depends on many other frameworks
just as well. It's random to choose Plasma just because it shares
maintainership.
Aleix
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 30, 2014 \
at 7:06 PM, Marco Martin <span dir="ltr"><<a href="mailto:notmart@gmail.com" \
target="_blank">notmart@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
class="">On Monday 30 June 2014, Jonathan Riddell wrote:<br>
> At the Hangout meeting today it was decided to go with a three month<br>
> release cycle and bug fix branch and to use this cycle for 5.0 and 5.1.<br>
><br>
> I've updated the schedule <a \
href="http://techbase.kde.org/Schedules/Plasma_5" \
target="_blank">http://techbase.kde.org/Schedules/Plasma_5</a><br> ><br>
> RC tagging and tars this Thursday<br>
> 5.0 tagging next Thursday when I'll make 5.0 branches too<br>
> Four week later is 5.0.1 from stable branch<br>
> Four weeks later is 5.0.2 from stable branch<br>
> A week after that and is 5.1 beta and freeze for features and messages<br>
> Four weeks later is 5.1 release<br>
<br>
</div>not completely sure the bugfix branches would be used that much, I guess we<br>
have to see how we can work with it<br>
<br>
one thing that occurred to me after the hangout this morning, is that the<br>
plasma-framework part that is a big part would have the one month schedule,<br>
while the workspace parts would be 3 months, that sounds kinda weird.<br>
but i guess we could say no features on every third release of plasma-<br>
framework, so synchs with the workspace.<br></blockquote><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
last thing, if the workspace has a slower cycle than all the frameworks, means<br>
that it should always work with several frameworks releases at once, since we<br>
wouldn't know what mix of version ends up in a \
distribution.<br><br></blockquote></div><br></div><div \
class="gmail_extra"><div>It's quite unfortunate the fact that we'll have a \
more schedule for the frameworks and then the workspaces won't be able to take \
advantage of those.</div>
<div><br></div><div>I don't think it makes sense to decide to stop the \
development on a plasma-framework, because after-all plasma depends on many other \
frameworks just as well. It's random to choose Plasma just because it shares \
maintainership.</div>
<div><br></div><div>Aleix</div></div></div>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic