Releases schedules and policy

[Thomas Senyk]

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?

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

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


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.! 
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