Build Master: Scheduling

[Xavier Bigand]

Le 14/11/2013 09:39, luka8088 a écrit :
> On 14.11.2013. 5:29, Tyro[17] wrote:
>> On 11/13/13, 11:06 PM, Brad Roberts wrote:
>>> On 11/13/13 7:13 PM, Tyro[17] wrote:
>>>> On 11/13/13, 9:46 PM, Brad Roberts wrote:
>>>>> On 11/13/13 4:37 PM, Tyro[17] wrote:
>>>>>> I'm of the opinion, however, that
>>>>>> the cycle should be six months long. This particular schedule is not
>>>>>> of my own crafting but I
>>>>>> believe it to be sound and worthy of emulation:
>>>>>
>>>>> I think 6 months between releases is entirely too long.  I'd really
>>>>> like
>>>>> us to be back closer to the once every month or two rather than only
>>>>> twice a year.  The pace of change is high and increasing (which is a
>>>>> good thing).  Release early and often yields a smoother rate of
>>>>> introducing those changes to the non-bleeding-edge part of the
>>>>> community.  The larger the set of changes landing in a release the more
>>>>> likely it is to be a painful, breaking, experience.
>>>>
>>>> Surely for those of us that live on the edge, it is fun to be able to
>>>> use the latest and greatest.
>>>> Hence the reason for monthly release of betas. Within a month
>>>> (sometimes shorter) of any new feature
>>>> being implemented in the language, you'll be able to download the
>>>> binaries for your favorite distro
>>>> and begin testing it.
>>>>
>>>> The side effect is that there is more time to flesh out a particular
>>>> implementation and get it
>>>> corrected prior to it being an irreversible eyesore in the language.
>>>> You also have a greater play in
>>>> the filing bug reports as to aid in minimizing the number of bugs that
>>>> make it into the final release.
>>>>
>>>> Unlike us adventurers however, companies require a more stable
>>>> environment to work in. As such, the
>>>> six month cycle provides a dependable time frame in which they can
>>>> expect to see only bugfixes in to
>>>> the current release in use.
>>>>
>>>> I think this release plan is a reasonable compromise for both parties.
>>>
>>> Companies that don't want frequent changes can just skip releases, using
>>> whatever update frequency meets their desires.  Companies do this
>>> already all the time.  That only issue there is how long we continue to
>>> backport fixes into past releases.  So far we've done very minimal
>>> backporting.
>>>
>>>
>>
>> And what I am proposing is that we start backporting to stable releases
>> and with subsequent bugfix releases.
>>
>> I'm also suggesting that for people interested in a more frequent
>> release will have at least five, if not more, such releases (betas)
>> prior to the official release. Live on the edge... use the beta. That's
>> what we do now.
>>
>> At the moment there's nothing that make dmd.2.064.2 any more bug free
>> than its previously released counterparts. Very few people participated
>> in the review of the betas which were released arbitrarily (when the
>> time seemed right). We simply call on of those betas dmd.2.064.2 and
>> moved on. It still has a slew of bugs and more are discovered daily as
>> people start to finally use the so called  "release".
>>
>> I'm saying we are go about it a little different. We get more people
>> involved in the testing process by providing more frequent release of
>> betas and getting much of the bugs identified fixed before designating a
>> release. To me you get what your are after a faster turnaround on fixes
>> (monthly). And the broader customer base gets a more stable product with
>> less bugs.
>>
>
> Just a wild thought...
>
> Maybe we can have monthly release and still keep it stable. Imagine this
> kind of release schedule:
>
> Month #  11          12          1           2           3
>
>           2.064       2.065       2.066       2.067       2.068
>           2.065rc2    2.066rc2    2.067rc2    2.068rc2    2.069rc2
>           2.066rc1    2.067rc1    2.068rc1    2.069rc1    2.070rc1
>           2.067b2     2.068b2     2.069b2     2.070b2     2.071b2
>           2.068b1     2.069b1     2.070b1     2.071b1     2.072b1
>           2.069alpha  2.070alpha  2.071alpha  2.072alpha  2.073alpha
>
> Where new features are only added to alpha release. And bug fixes are
> added to all releases.
>
> This way new bug fixes and new features would be released every month
> but there would be a 5 month delay between the time that feature A is
> added to the alpha release and the time feature A is propagated to the
> stable release. But during this period feature A would be propagated
> through releases and there would be plenty of opportunity to test it and
> clear it of bugs. I am not a fan of such delay but I don't see any other
> way new features could be added without higher risk of bugs.
>
> Also vote up for daily snapshots.
>
As pure D user, I am not really comfortable with having to wait 6 months 
between releases. I like the idea to get new small features regularly 
(phobos API enhancement,...), and on some release getting a long wait 
hudge feature like Allocators.
Small releases will help to community to live with D. It's important to 
make noise regularly around the "product". Users will also xp more 
progressively in their development.

There is a lot of development I am waiting for my project, I'll really 
be happy to see one come before the next summer :
  - std.logger
  - std.serialization
  - Weak Ptr
  - New signals/slots
  - RPC (Remote procedure call)
  - AST Macro