On Thursday, 14 November 2013 at 20:53:05 UTC, deadalnix wrote:
> ...

Hush-hush :) I was simply answering a question "Why may someone refuse to move to minor release that contains only bug fixes". Nothing more, nothing less, no hidden implications :)

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

I have no idea what everyone is getting worked up about. My understanding of the plan is that there are biannual major releases, with bug fix releases in-between, for those people/companies who need stability/dependability.

In addition to that we have monthly 'beta' releases for those who want the latest and greatest but know that a few things may get changed around between the releases that break code and that there are likely to be more bugs.

So all the passionate D devs here get their monthly releases, and the people who want maximum stability get a biannual, LTS release along with some bug fix releases.

On 11/14/2013 09:18 AM, tn wrote:
> What is wrong with the process that is described in the wiki (and that I
> thought you already agreed on)? See
>
> http://wiki.dlang.org/Development_and_Release_Process

It's too complex.

On 11/15/2013 12:36 AM, Nick wrote:
> I have no idea what everyone is getting worked up about. My
> understanding of the plan is that there are biannual major releases,
> with bug fix releases in-between, for those people/companies who need
> stability/dependability.
>
> In addition to that we have monthly 'beta' releases for those who want
> the latest and greatest but know that a few things may get changed
> around between the releases that break code and that there are likely to
> be more bugs.
>
> So all the passionate D devs here get their monthly releases, and the
> people who want maximum stability get a biannual, LTS release along with
> some bug fix releases.

I too think it's a good plan. Many new features need a few month until they are stable.
Also the 6 month nicely match our deprecation cycle.
There is only one maintenance release in parallel to the master/beta branch which reduces the backporting effort.
We still need automate more of the release building.

On Thursday, 14 November 2013 at 20:30:40 UTC, Dicebot wrote:
> On Thursday, 14 November 2013 at 20:27:23 UTC, Rob T wrote:
>> Bug fixes should be as frequent as possible. To understand why, just try and find a good reason to artificially hold back a bug fix.
>
> Code breakage. DMD has good amount of accepts-invalid bugs.

Code that is invalid but compiles is already broken by definition. These are potentially silent bugs in the code base, which are never good for anyone. I'd rather know about accepted-invalid code sooner in a development environment than later in an production environment.

Furthermore, holding back on fixing accepts-invalid will allow more invalid code to sneak into the ever expanding code base, making the problem worse over time.

--rt

On Friday, 15 November 2013 at 00:30:09 UTC, Martin Nowak wrote:
> On 11/14/2013 09:18 AM, tn wrote:
>> What is wrong with the process that is described in the wiki (and that I
>> thought you already agreed on)? See
>>
>> http://wiki.dlang.org/Development_and_Release_Process
>
> It's too complex.

How? It is the same as Tyro[17] describes only with 2 month rather than 6 month releases. The page just goes into great detail about how to achieve it, which is complex.

On 2013-11-15 02:33, Jesse Phillips wrote:

> How? It is the same as Tyro[17] describes only with 2 month rather than
> 6 month releases. The page just goes into great detail about how to
> achieve it, which is complex.

Yeah, it has all the git commands, you don't have to read those.

-- 
/Jacob Carlborg

On 2013-11-15 00:36, Nick wrote:
> I have no idea what everyone is getting worked up about. My
> understanding of the plan is that there are biannual major releases,
> with bug fix releases in-between, for those people/companies who need
> stability/dependability.
>
> In addition to that we have monthly 'beta' releases for those who want
> the latest and greatest but know that a few things may get changed
> around between the releases that break code and that there are likely to
> be more bugs.
>
> So all the passionate D devs here get their monthly releases, and the
> people who want maximum stability get a biannual, LTS release along with
> some bug fix releases.

The opposite of an LTS release is _not_ a beta release. It's a regular release. It seems it would be better if the beta release were regular releases and the releases were LTS releases.

I'm having a hard time requiring my users to use anything that is not a release (that is, a beta).

-- 
/Jacob Carlborg

tl;dr thread.

What about release circle as debian project have.

Stable (LTS) release, for example, each year or each 3 versions with backports available.

Testing release, for example, each month.

Unstable (head revision), each week?

Naming:

dmd-2.065.0-2013.11.15-unstable.zip,
dmd-2.065.0-2013.11.11-testing.zip,
dmd-2.065.2.zip stable release with 2 update.

dmd-unstable.zip - latest head rev build.
dmd-testing.zip - latest testing/feature build.
dmd-stable.zip - latest stable / LTS.