Releases schedules and policy

[BogDan]

> If I got you right the 2 options are:

> 
> A: 2 release:
>     alpha3: more or less current state
>     alpha4: more or less current state + Java-interface-rewrite
> 
> or B: 1 release named alpha3: "more or less current state + Java-interface-
> rewrite"  (as alpha4 in PlanA)
> 
> right?
> 

Right !

> And after that we might need another alpha if we want to break API/ABI before 
> release?
> 

Right !

>
> The last alpha is named beta as soon as it's API/ABI stability is confirmed?
> 

Yes, let's say one month after release.

> 
> I personally like more and smaller releases => I would vote for PlanA ... 
> but your right 2-3 weeks delay is properly not worth it.
> 
> 
> I totally agree with Oct.15.! 

Oct.15 is for Plan B, if we decide to go with that one.

>
> I want to show people opengl-accelerated apps out of the app-store :)
> 
> 
> 
> As soon as we get the next release I write a blog-post  on labs.qt.nokia.com 
> ... unless some else wants to :)
> (and push the qmlshowcase to android-market)
> 
> 
> Greets
> Thomas
> 
> 
> On Wednesday, September 14, 2011 02:31:28 PM ext BogDan wrote:
>>  Hi folks,
>> 
>>  I want to share with you my thoughts/plans for next releases, also I have a
>>  proposal regarding releasing policy. Any feedback is highly appreciated !
>> 
>>  ====Releases schedules ====
>>  Plan A:
>> 
>>    As you may know, currently we are trying to release Necessitas alpha3, we
>>  still need to implement some missing things to SDK Installer, also I've
>>  seen some show stopper issues, which must be fixed before release, the plan
>>  is to try to release it this month, and it should be the last but one alpha
>>  release.
>> 
>>    After this release we'll need 2-3 weeks to redesign Ministro and Java
>>  part, then we don't have to worry about java <==> android 
> platform
>>  incompatibility, so we can release last alpha. After a few weeks, *IF NO*
>>  regressions are reported we can rename the release as beta which will
>>  *GUARANTEE* API/ABI compatibility. If someone will report issues which to
>>  fix them we'll break API/ABI compatibility, we must release another 
> alpha.
>> 
>>  ----------------------------------------------
>> 
>>  Plan B:
>> 
>>    Delay with one month this release, meanwhile we'll do our best to 
> redesign
>>  Java part and Minitro, so alpha 3 release should be last alpha release,
>>  then, after a few weeks *IF NO* regressions are reported we can rename the
>>  release as beta.
>>  I'd like to have this alpha shipped *BEFORE* Qt dev days ! :) So we 
> must
>>  have everything in place before Oct. 15 !
>> 
>>  IMHO plan B is better, because this way we can ship fist beta earlier with
>>  at least 2-3 weeks (the time needed to create and test a SDK for a
>>  release).
>> 
>>  We need to decide which plan we'll use, so your thoughts are very 
> welcome.
>> 
>> 
>> 
>>  ====Releases policy ====
>> 
>>    Before we release first beta we also must have a policy about what
>>  branches will use to release a Ministro repository and who is allowed to
>>  push in those branches.
>>  First I want to share with you current architecture, Ministro is using 3
>>  different repositories similarly with Debian (which IMHO is one of the most
>>  successfully community project out there, so I want to follow their path):
>>  1 - *unstable*
>>  2 - *testing*
>>  3 - *stable* default repository used by Ministro.
>> 
>>  Ministro is using *stable* repository by default, and to change it you need
>>  to download another tool (Ministro Configuration Tool),  this tool can be
>>  use by developer to test their apps against *unstable* and *testing* repos.
>> 
>>  Who it works ?
>>  Every new release will go first into *unstable* repo, there it should stay 
> a
>>  while (IMHO it should be at least one month), then if *NO REGRESSION(s)*
>>  are reported we'll move it to *testing* repository, then again it 
> should
>>  stay another month for further testing, then if nobody reports *REGRESSION*
>>  we'll move it into *stable*, of course no new releases with new 
> features
>>  will be released until this release will land on stable repository. This
>>  way every developer has the chance to stop a release if it will break his
>>  existing apps on Android Market, so, if you are a developer and you have an
>>  application deployed on Market, you only need to download Ministro
>>  Configuration Tool, change Minsitro repository, and test your application
>>  against new qt libs.
>> 
>>  Because Minsitro uses 3 repositories we should also use 3 branches for qt,
>>  qtcreator, webkit, etc. with the same names. This branches are very
>>  important, so, we should create some rules, e.g. who has the right to push
>>  into this branches and in what conditions. My proposal is nobody should
>>  push directly to this branches, without a discussion on this mailing list
>>  and without a review by other two (or more) Necessitas developers.
>> 
>> 
>>  Also on this topic I need your feedback !
>> 
>>  Sorry for the big post :)
>>  Thank you for your time !
>> 
>>  Cheers,
>>  BogDan.
>>  _______________________________________________
>>  Necessitas-devel mailing list
>>  Necessitas-devel at kde.org
>>  https://mail.kde.org/mailman/listinfo/necessitas-devel
>