Releases schedules and policy

Thu Sep 15 15:17:33 UTC 2011

I kind of feel like it might be good to do a plan A release just to help
shake out more bugs for the potential beta and still go for oct 15th too.

Maybe if the new test suite stuff works we can test for an immediate release
and if it all looks ok then do it? Of course the installer stuff would need
fixing for this, but that stuff needs fixing anyway?
On Sep 15, 2011 3:58 PM, "BogDan" <bog_dan_ro at yahoo.com> wrote:
>> 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
>>
> _______________________________________________
> Necessitas-devel mailing list
> Necessitas-devel at kde.org
> https://mail.kde.org/mailman/listinfo/necessitas-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/necessitas-devel/attachments/20110915/8a860fa1/attachment.html>