On 14.11.2013. 10:55, Jacob Carlborg wrote:
> On 2013-11-14 09:39, luka8088 wrote:
> 
>> 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.
> 
> Are you saying we should have six releases going on at the same time?
> 

Yes. For example, if you have version 0.1, 0.2 and 0.3. And you find and fix a bug in 0.3 but you still wish to support backport for 0.2 and 0.1 that you indeed need to make 3 releases. 0.1.1, 0.2.1 and 0.3.1.

But then again having LTS that others have mentioned seems better. So that only each nth release has 2.x.1, 2.x.2, 2.x.3.

From my perspective, not separating releases with improvements + bug fixes from releases with only bug fixes is an issue. Because every new improvement implies risk of new bugs and some users just want to have one version that is as stable as possible.

What do you all think about http://semver.org/ ?
We use this king of versioning notation at work and it turns out to be
very good.

On Thursday, 14 November 2013 at 00:37:38 UTC, Tyro[17] wrote:
> 
> Bugfix releases (2.064.1)
>     Based on the previous major release or bugfix; contains only bugfixes and perhaps documentation corrections.
>
>
> Your thoughts and concerns please.

Do you happen to work with me? We have two dozens of such releases branch :) And customers still tend to prefer the slightly bleeding edge ones.

While this effectively _does_ work in creating more stable releases, I think that it puts all the burden on the developers in a way that is difficult to ignore.

Most of the time backporting is little work, but sometimes you need to redo a fix you already did, for a branch which only exist to be phased out a bit later, in a codebase slightly different in ways nobody can tell anymore. Sometimes it's even very hard to backport a fix, but if you don't do it how to tell which branch has which bugs?

Coupled with being forced to backport every bugfix to every branch, this can make a compelling enough reason never to contribute.

With a typical bad fix injection rate of ~5%, this also mean regressions will crop up in release branches and never be noticed since they are not introduced at HEAD level but by the very act of backporting.

I'm not sure it can be done in a way that feels right. I prefer the N-month release cycle we have, and take as much time and Release Candidates as needed.

On 15.11.2013. 0:22, Xavier Bigand wrote:
> 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
> 

Yes but not having a delay between the time a new feature is implemented and the time it is released is very risky in terms of bugs. Because this new features has not been tester properly. And that is a fact.

As far as I see it. Nobody is against frequent releases, but some people (including me) are against calling them stable. Because for people who depend on stability they are not stable enough. And calling them a release and not calling them beta (or something like that) implies stability. And especially if there is nothing like LTS then it implies "this is the most stable there is".

On 2013-11-15 10:16, luka8088 wrote:

> Yes. For example, if you have version 0.1, 0.2 and 0.3. And you find and
> fix a bug in 0.3 but you still wish to support backport for 0.2 and 0.1
> that you indeed need to make 3 releases. 0.1.1, 0.2.1 and 0.3.1.

There's a difference in still supporting old releases and working on five different releases at the same time that hasn't been released at all.

> But then again having LTS that others have mentioned seems better. So
> that only each nth release has 2.x.1, 2.x.2, 2.x.3.
>
>  From my perspective, not separating releases with improvements + bug
> fixes from releases with only bug fixes is an issue. Because every new
> improvement implies risk of new bugs and some users just want to have
> one version that is as stable as possible.
>
> What do you all think about http://semver.org/ ?
> We use this king of versioning notation at work and it turns out to be
> very good.

I like it but I'm not sure who it's applied to applications. It's clear to see how it works for libraries but not for applications. I mean, what is considered an API change for an application? Changing the command line flags?

-- 
/Jacob Carlborg

On 2013-11-15 00:22, Xavier Bigand wrote:

> 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'm wondering if we can managed to release the compiler and Phobos and independently.

-- 
/Jacob Carlborg

On Friday, November 15, 2013 11:03:37 Jacob Carlborg wrote:
> On 2013-11-15 00:22, Xavier Bigand wrote:
> > 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'm wondering if we can managed to release the compiler and Phobos and independently.

I don't think so. It's still far too often the case that something has to be tweaked in Phobos because of a compiler change (generally for bug fixes, but that arguably doesn't matter much - it prevents separating their releases regardless).

- Jonathan M Davis

On 15.11.2013. 11:01, Jacob Carlborg wrote:
> On 2013-11-15 10:16, luka8088 wrote:
> 
>> Yes. For example, if you have version 0.1, 0.2 and 0.3. And you find and fix a bug in 0.3 but you still wish to support backport for 0.2 and 0.1 that you indeed need to make 3 releases. 0.1.1, 0.2.1 and 0.3.1.
> 
> There's a difference in still supporting old releases and working on
> five different releases at the same time that hasn't been released at all.

Yeah. I agree. Bad idea.

> 
>> But then again having LTS that others have mentioned seems better. So that only each nth release has 2.x.1, 2.x.2, 2.x.3.
>>
>>  From my perspective, not separating releases with improvements + bug
>> fixes from releases with only bug fixes is an issue. Because every new
>> improvement implies risk of new bugs and some users just want to have
>> one version that is as stable as possible.
>>
>> What do you all think about http://semver.org/ ?
>> We use this king of versioning notation at work and it turns out to be
>> very good.
> 
> I like it but I'm not sure who it's applied to applications. It's clear to see how it works for libraries but not for applications. I mean, what is considered an API change for an application? Changing the command line flags?
> 

I think API change could be analog to features change (and the way they
are interfaced).

So the version consists of x.y.z

z increments only on bug fixes.
y increments when new features are added, but they are backwards
compatable. Incrementing y resets z to 0.
x increments when backwards incompatible change are made. Incrementing x
resets y and z to 0.

On 2013-11-15 11:51, luka8088 wrote:

> I think API change could be analog to features change (and the way they
> are interfaced).
>
> So the version consists of x.y.z
>
> z increments only on bug fixes.
> y increments when new features are added, but they are backwards
> compatable. Incrementing y resets z to 0.
> x increments when backwards incompatible change are made. Incrementing x
> resets y and z to 0.

The problem is that it's very easy to break code, even with bug fixes.

-- 
/Jacob Carlborg

On Friday, 15 November 2013 at 09:17:45 UTC, ponce wrote:
> Do you happen to work with me? We have two dozens of such releases branch :) And customers still tend to prefer the slightly bleeding edge ones.
>
> While this effectively _does_ work in creating more stable releases, I think that it puts all the burden on the developers in a way that is difficult to ignore.
>
> Most of the time backporting is little work, but sometimes you need to redo a fix you already did, for a branch which only exist to be phased out a bit later, in a codebase slightly different in ways nobody can tell anymore. Sometimes it's even very hard to backport a fix, but if you don't do it how to tell which branch has which bugs?
>
> Coupled with being forced to backport every bugfix to every branch, this can make a compelling enough reason never to contribute.
>
> With a typical bad fix injection rate of ~5%, this also mean regressions will crop up in release branches and never be noticed since they are not introduced at HEAD level but by the very act of backporting.
>
> I'm not sure it can be done in a way that feels right. I prefer the N-month release cycle we have, and take as much time and Release Candidates as needed.

That's the exact problem with most of the release ideas proposed here, they are terribly inefficient.
The schedule proposed by Andrew only requires one maintenance branch (point releases) besides the regular beta releases from master. Backporting to a single stable branch should be within our budget.

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

The point is, there has never been a really stable dmd release.
Using it requires to read the mailing list just like with most beta software.
We won't be able to release a stable compiler every month anytime soon.