Jump to content

- - - - -

WinBuilder Development Plan

  • Please log in to reply
1 reply to this topic

#1 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10562 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
    European Union

Posted 23 February 2010 - 01:56 AM

It is no surprise that we need to improve the way how WinBuilder is developed and we all agree that something needs to be done. But for this to happen, we need your help.

On this topic we will define how WinBuilder will be developed across future versions with the help of everyone that is interested in join. Everyone is welcome to help.

This is what you can expect inside this topic:

- Development phases
- Bug Reporting
- Experiments
- Best practices


Development Phases
  • Alpha
  • Beta
  • RC
  • Stable
We adopt the names that everyone knows and is familiar. I will now detail what each one means inside our context:

They replace the current "trash" releases. The only version number that alpha uses is in the format of yymmdd, for example: WinBuilder_100222.exe
Alpha releases are only available on DEFCON section of the forum and should not be used in official projects. There are no limitations on the number of alpha releases but only developers allowed to use DEFCON provide direct feedback with developers.

Ideally, only one beta release is released to the public at the public forum. This is the time when public feedback on the beta is welcome to test the new features and see their opinion. If only minor bugs are reported, alpha releases are used to correct them and we move onto the next phase. If more than one beta is needed it's a sign that alphas are not being used correctly. We label beta with an odd release number, for example, wb 081.
Although it's public, it shouldn't be used for official projects.

RC (Release Candidate)
This the second public phase. When a RC is made available, there should only be need for small cosmetic changes at most. It should be made available for at least one week before the next phase. If bugs are still reported, they should be addressed for future versions. RC's are meant as a preparation period for project developers to adapt and prepare their projects, not as a phase for wb developers to modify winbuilder.exe

After RC is approved, we pass to the stable version and label it with an even number, for example wb 082. Announcement is made on the forum and projects are updated with new stable version as soon as possible.


Bug Reporting

Reporting on the bug tracker forum section is critical:

It is ok to have one huge discussion topic while testing alpha wb's but each bug found on stable and beta versions should have it's own topic inside the bugtracker and be strictly discussed there. We need people to use this method to keep focus and track of which bugs will be prioritized for the next versions. Having a bug reported over there will allow transparency to see which bugs were already addressed to everyone.



There will be a test project to validate the functioning of WinBuilder. This project is maintained by designated .script developers.

Inside this test project there will be test cases to validate the functionality of a given winbuilder.exe. We know that winbuilder will evolve as time passes and this project is also by itself a work in motion that is used to ensure that wb is working as intended.

We need that testers use/write these test cases to ensure that everyone else (including wb developers) are capable of replicating the buggy or intended behavior of winbuilder.

A subdomain http://testing.winbuilder.net will be made available to host the test project.

Whenever testing, please add the relevant details to help replicate the behavior and beware that only during alpha and beta releases will be possible to make relevant changes.


Best practices

From a wb development perspective. We will try to provide stable releases within each 3~4 months where alpha, beta and RC versions are released in the meanwhile as necessary. It's not a static deadline but we'll aim to this value whenever possible.

Not all reported bugs will be solved one each version. This is not humanly possible and will only delay the release of a needed stable.

Please refrain from using alpha, beta or RC versions inside any stable project because we'll also be trying to release stables more often.

After each stable being released, we will identify, discuss and prioritize on the following week what is necessary to have available on the next stable.


If we all respect these simple interaction rules, things become much better for everyone.

You're welcome to post questions or comments about this plan.


#2 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10562 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
    European Union

Posted 23 February 2010 - 01:57 AM


This topic is reserved for placing answers to often asked questions or other snippets of information.

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users